IR receiver suddenly stopped working

[Quantumcross]

I’ve been happily using my DIY OSSC for about a year now.

I ordered the remote sticker overlay from the other store that carries it (in the UK) and I popped it on my remote. I decided to reprogram the OSSC so that the mappings properly match the sticker.

Half-way through the OSSC learning mode, the OSSC suddenly stopped receiving IR signals. The light does not flash on the OSSC, it will not respond to “Press 1” after re-entering learning mode, and it will not respond to any commands when operating normally.

The OSSC still seems to function just fine, it just won’t respond to IR at all. The solder joints on the IR receiver look just fine.

Any ideas?

[Quantumcross]

So I’ve done some diagnostics and I still can’t figure out what’s wrong here.

Here is the list of things I did:

• checked VccIO on IR ~ 3.25V
• checked GND on IR connected
• checked R33 connected to VccIO and IR pin 1
• checked IR pin 1 and R33 connected to pin 23 on FPGA
• Signals are shown on oscilloscope in Vout of IR when remote is pressed ( I don’t understand the signal but there are definitely pulses there
• Completely replaced IR receiver module
• Tried 3 different working remotes

It still does not work and I am out of ideas. Please help me!!! This OSSC is used in a streaming setup and we would like to get it working as soon as possible!!!

[marqs]

Looks like you’ve troubleshooted the most likely causes without luck. You could try reflowing nearby FPGA pins that are on the same IO bank, especially VCCIO and GND (17,19,22). If you have a USB Blaster, you might also want to try reflashing firmware as well. Check also that Y1 outputs 27MHz signal. Problems with supplies, fw or oscillator should cause other issues as well, but those are the only reasons I can think of now in addition of very unlikely FPGA pin breakdown.

[Quantumcross]

Thank you so much for the response.

I do have a USB blaster, I am worried that if I reflash the firmware I will lose my current settings with no way to dial in new ones. This OSSC is currently used nearly daily in a streaming setup and I would not want it to be stuck at a generic 2x mode.
— Is the state of all the settings stored in the eeprom? If I dump it first before reflashing, can I reflash a dump to get it back exactly in the same state it is in now? Can I dump the current state of the eeprom with the usb blaster or should I use an external dumper?

I don’t have a device that can measure the Y1 frequency, but everything else on the device is working fine, the 4x scale mode that it was stuck on when the IR stopped working, hdmi audio (with the addon board), etc.

I did get the FPGA from aliexpress, so maybe it actually could be a bum chip?

[marqs]

— Is the state of all the settings stored in the eeprom? If I dump it first before reflashing, can I reflash a dump to get it back exactly in the same state it is in now? Can I dump the current state of the eeprom with the usb blaster or should I use an external dumper?

Settings are stored on same the flash chip that houses FPGA bitstream. Updating the firmware does not technically erase the part of flash that contains them, but settings made using other fw versions are not read since there are no code to validate them. This applies to update via SD card, but JTAG update should be the same (unless altera tools make a full chip-erase which I highly doubt). So as long as you flash the same version, your settings should persist.

I don’t have a device that can measure the Y1 frequency, but everything else on the device is working fine, the 4x scale mode that it was stuck on when the IR stopped working, hdmi audio (with the addon board), etc.

It’s highly unlikely that Y1 frequency would have drifted significantly, but that would at least explain why IR signals are not recognized (would also cause testpattern refresh rate to change from 60Hz).

I did get the FPGA from aliexpress, so maybe it actually could be a bum chip?

There’s always a chance that you’ve got a chip that has been rejected by QC and still found some way to market. Not knowing the origin/supply chain is the downside of ordering chips from Aliexpress.

[Quantumcross]

Hi marqs, I just reflowed the FPGA and reflashed the same version of the firmware over JTAG, and it seems to have reverted the settings to default.

The IR reciever is still not working, so now the OSSC is stuck in 2x mode 🙁

Do you have any more ideas for me to try…?

[Quantumcross]

Since the settings are already gone, I flashed the latest jtag version and it still doesn’t work.

For what it’s worth, our datapath vision capture card is reporting that the test pattern is 59.94 hz.

[marqs]

Hi marqs, I just reflowed the FPGA and reflashed the same version of the firmware over JTAG, and it seems to have reverted the settings to default.

That’s unfortunate, it seems Quartus programmer makes a full chip erase after all :(.

To test whether the FPGA pin is stuck at 0 or 1, you could desolder R33 and measure (ossc turned off) resistance and diode voltage from the open pad (FPGA-side) to GND and VCCIO.

[Quantumcross]

Thanks, I’ll try this tonight.

[Quantumcross]

Removed R33

Resistance test:

- on IR_RX, + on VCCIO: 19.2kOhm
- on IR_RX, + on GND  : 19.2kOhm
+ on IR_RX, - on VCCIO: 39.2kOhm
+ on IR_RX, - on GND  : 40.2kOhm

Diode test:

- on IR_RX, + on VCCIO: 0.829V
- on IR_RX, + on GND  : 0.460V
+ on IR_RX, - on VCCIO: 0.727V
+ on IR_RX, - on GND  : 0.820V

[marqs]

The first and last result on your diode test seem off as you shouldn’t see forward bias from VCCIO or to GND. Perhaps there’s something broken indeed – you might want to desolder IR receiver or lift that FPGA pin and redo the test.

[Quantumcross]

Ok, thanks for interpreting that for me, I don’t quite understand it yet. I will desolder the IR receiver and R33 and do the tests again.

Today I received a busted OSSC (failed HDMI upgrade) that I’m hoping to repair tonight as well. If I can get that one working I will feel much more comfortable doing more invasive diagnostics with the first one 🙂

[Author]

Posts