OSSC v1.8 freezing and behaving strangely

[rt]

I’ve bought an OSSC v1.8 from VGP about two years ago. I think it had firmware v1.07 or v1.08 installed before I’ve upgraded to v1.20 a few days ago. The update succeeded and then I have used the device for that evening.

On the next day, the OSSC failed to start up properly. The OSSC showed its startup message displaying the firmware version (1.20), but didn’t react to any input. HDMI output was generated, showing the test image, but otherwise the device seemed dead. I tried various things, power cycled a few times, then suddenly I was able to change inputs using button 0, only the input names were messed up (garbled strings). The same garbled strings were visible on the TV. Opening the menu didn’t work because the OSSC still didn’t react to the remote control.

Unable to change the firmware from the menu, I grabbed my USB Blaster, installed Quartus Prime Lite, and followed the instructions for installing firmware via JTAG. Since there is no .jic file for v1.20 on the GitHub release page, I’ve used the ossc_1.01-aud.jic file as found at http://www.infocult.com/m/ossc/fw/v1-series/ (linked from https://junkerhq.net/xrgb/index.php) for the purpose of upgrading to 1.20 again.

Quartus detected the device, flashed the firmware, but the CRC verification step failed. Anyway, the OSSC display showed 1.01a, the remote control worked again, and I was able to open the menu, so I played around a bit. Then, the OSSC started freezing and behaved similar to before with firmware 1.20. JTAG revived the device again, again with CRC error, and it stopped working again after a few minutes of use. I’ve flashed several times, tried other .jic files, but the CRC verification step failed each time.

Given that I see these CRC errors, I guess that the SPI flash memory chip (U10, labeled IS25LP016 DNLE) might be broken. Is there a way to confirm this? Or could there be something else which may cause the problems I have? I want to be reasonably sure about this, as the IC is rather difficult to find and also quite expensive.

Thank you!

[rt]

So, I started measuring a bit. Voltages on the regulators were off, first just a little bit, then it got worse and suddenly the display light went out. Fuse F1 got very hot and had a resistance of around 24 ohms (measured after having removed it).

I’ve bridged the fuse with an ammeter, and according to that, the whole device draws around 229 mA. Does this sound about right or is this too much already? Maybe it was just a bad fuse after all…

• This reply was modified 3 months, 3 weeks ago by rt.

[marqs]

229mA sounds a bit low if there is an analog input active, but possibly normal if it’s idle / outputting just test pattern.

[rt]

Yes, it was just the PCB without any cables other than the PSU connected, as idle as can be. Good to hear that this might be normal.

I’ve ordered some new fuses and will check again after having replaced it. I don’t want to risk frying anything by bypassing the fuse for longer than necessary.

[rt]

Finally, I have received and installed my replacement fuse. CRC verification still fails when flashing the firmware via JTAG, but that very firmware was able to upgrade the device to v1.20 from SD card regardless (no errors displayed).

The OSSC worked for some time. I could set it up for my Amiga 500 and play Battle Squadron for about 15 minutes. I’ve played a bit with OSSC settings during that time, then it suddenly started to fail to open the menu. Power-cycling didn’t change that, no reactions to the remote control anymore. The OSSC still produces video data, activation of AV1 still works by pushing button 0, I can still play Battle Squadron, but there is no way to open the configuration menu…

So, I’m back to square one, sort of. Voltages at U5, U6, U7, U9, U18 are all fine, the fuse is still good, no hot chips.

What to do now? Just exchange the flash memory and hope for the best? Is there something else I should check before replacing the flash IC?

I found an offer on eBay for 5 pieces of IS25LP016D-JNLA3-TR for about 12.50 Euros. And I’ve found another, much cheaper offer for an IS25LP032D-JBLE (32 Mbit, 4M x 8 bit, SOIC-8). Will that work, too, or does the software expect a 16 Mbit chip?

[rt]

I bought those IS25LP016D-JNLA3 chips and replaced U10 by one of them. These ICs have extended temperature range ratings, otherwise they are the same as the regular ones. Initial flashing worked like it did before, including the CRC verification error. Still the device started to work, but I had to configure the remote control buttons. Upgrade to v1.20 succeeded, and again I had to configure the remote control buttons… Anyway, the OSSC is up and running and appears to be stable now!

I’m just wondering why I’m still getting CRC errors when flashing via JTAG. It leaves me with an uneasy feeling.

[marqs]

Is your remote certainly in the OSSC mode (set via blue “TV” button)? It sounds like it’s using one of the other presets (Pro/Framemeister) if you need to configure it again after settings reset. That reminds I should update the binding function to display the key codes as Pro.

I’ve never seen CRC errors during JTAG programming, only (flash) device ID mismatches which can be ignored.

[rt]

Ha, the remote was indeed not in OSSC mode! 😅 Thanks for pointing that out, “problem” fixed.

Could the CRC errors possibly have something to do with my JTAG? I bought my USB Blaster more than 10 years ago for around 8 Euros; it’s certainly a clone. Since then, I’ve rarely used it, so I don’t really know how good (or bad) it really is. Working on Linux, by the way.

My OSSC still works perfectly after swapping out U10, so it looks like my flash broke halfway after some unknown incident which also burned the fuse. To help diagnosing a broken flash IC, maybe you could add a checksum check that can be invoked from the menu? That feature could compute the checksum from the firmware data stored on flash memory and compare it against the correct checksum stored right after the actual firmware data (or even use multiple checksums which cover smaller chunks of the firmware). Yes, this may sound like a useless feature, since damaged firmware should not be able to run at all. In my case, however, a complete update from the SD card, including checksum verification, passed with no errors, and the firmware even functioned correctly for a short time before it kind of disintegrated.

Oh, and it would be great if you could release a .jic file for v1.20 (and later).

Thank you for your time!

[Author]

Posts