0
\$\begingroup\$

Today I've faced a strange problem:

I have an LCD monitor controller board. It has an LCD panel driver chip having a 8051-based MCU inside, but the chip needs an external W25Q80 SPI flash for program memory. So the chip runs the program over SPI flash.

The problem is that it looks like the program inside the SPI flash has "gone". The monitor was running for about a month (12h per day).

So, is it common for these types of flash chips? What can be the the cause of the problem and what should I do?

\$\endgroup\$
  • \$\begingroup\$ Was the W25Q80 used for just ROM or was it being continuously written to as well? \$\endgroup\$ – Chris Knudsen Jul 2 '18 at 17:21
  • \$\begingroup\$ @ChrisKnudsen No, it's written just once while programming. \$\endgroup\$ – Rohat Kılıç Jul 2 '18 at 17:24
  • \$\begingroup\$ Can you still read the Release Power-down / Device ID (0xAB)? Can you reprogram the chip, and does it appear to function (at least temporarily)? \$\endgroup\$ – Chris Knudsen Jul 2 '18 at 19:05
  • \$\begingroup\$ @ChrisKnudsen I have a programmer and it connects directly to the LCD driver chip through I2C. The commands sent by programmer to the LCD driver are converted and sent to the flash chip via SPI. The programmer sees the chip and reads its ID. I can reprogram the chip with the programmer, the chip works fine after it but I'm still unsure about the stability. \$\endgroup\$ – Rohat Kılıç Jul 2 '18 at 21:09
  • \$\begingroup\$ I've just tried: I touched one of the SPI pins of the flash with a cable and the program just restarted by itself. I repeated the same thing and after a couple of touches the program has stopped and never started again even after power cycle. So I had to reprogram the chip. Maybe some parasitic signals/noise are affecting the chip. Can it be? \$\endgroup\$ – Rohat Kılıç Jul 2 '18 at 21:12
1
\$\begingroup\$

If you are really sure that flash is to be blamed (and not firmware or something else), then I would suggest you try using the device with flash write-protected. There is a pin for that, so it would be a minimal hardware modification (it can be a problem if the circuit uses for example Quad-SPI, because then the WP pin is not available).

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

Two things:

  1. You say device is working 12 hours per day for a month, and I guess these 12 hours are continuous hours. So the first thing comes to mind is temperature. Commercial version of flash device is rated for 0 to 70 C, however higher the temp, more probability for its misbehavior. Check the conditions and ensure that there's enough cooling around and insider the device.

  2. It may happen that the controller drives flash chip with write enable command issued when it must not be done so. If it is the case, then you touching SPI line may arbitrarily cause flash see "sector erase" command, or similar one, and thus perform this operation. To confirm or deny my theory you must have SPI interaction analyzed, and/or when corruption occurs, download flash contents and compare to original to find out some critical sector being filled with FF (erased). Such situations happened to me when driving serial configuration flash using FPGA, and it is absolutely necessary to have write disabled (not enabled - by command and electrically where possible) not to have bugs like you describe.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

The problem is solved in an interesting way.

According to the supplier, the previous version of the board has an analog input (something like CVBS) and a switch input for switching active display input source from HDMI or VGA to that analog input. Now the current version of the board does not contain both that analog input and the switch. So the corresponding pins of the controller chip are left open. But the controller has the software uploaded for the previous version of the board.

He said that since the switch input pin has left open, it could have picked up noise due to its high impedance and translated that to a switching input. And since the software is not updated, the controller tried to switch the input source to CVBS which is not provided and thus could not start.

Sounds like a logical explanation to me.

So, the statement "the software is gone" seems not true. That was totally a different situation.

Anyway, the problem is solved.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.