When I developed a TV project, something strange really bothered me for weeks. The CRT (Cathode Ray Tube) TV project was based upon a Philips 8051 TV microcontroller with on-chip OSD (On Screen Display) and Tuning features. The software was running on my emulator without any problems. So our customer decided to launch pilot production. The QA team found something strange in the internal audit procedure and notified me urgently. Among 12 TV sets, about 5 TV sets randomly showed the retrace scanning lines after AC switching on. The occurrence was unpredictable.

A picture is "drawn" on a television display screen by sweeping an electrical signal horizontally across the display one line at a time. The amplitude of this signal versus time represents the instantaneous brightness at that physical point on the display. At the end of each line, there is a portion of the waveform (horizontal blanking interval) that tells the scanning circuit in the display to retrace to the left edge of the display and then start scanning the next line. Once the first complete picture is scanned, there is another portion of the waveform (vertical blanking interval, not shown) that tells the scanning circuit to retrace to the top of the display and start scanning the next frame, or picture. This sequence is repeated periodically at a fast enough rate so that the displayed images are perceived to have continuous motion.

In a CRT TV, the normal video signal is visible on screen because the voltage of video signal is higher than reference black level. During blanking interval, the voltage of video signal is fixed at blanking level, which is lower than black level, so retrace line is invisible during this horizontal or vertical blanking.

Our customer and I spent one week on trying to figure out the root cause. We tried to check out its occurrence relationship with temperature in the torture room (I was almost freezing in that huge refrigerator), but we could not find out. We tried to debug on emulator, but software was fine. We had tried everything we had, we almost gave up.

Finally the customer captured the retrace scanning line with an oscilloscope. It was obvious that the additional OSD from microcontroller was enabled and the final video signal was higher than black level. The retrace scanning line displayed on screen was not valid video signal, but OSD signal. There was a bug in the software. But why did this bug never take place on emulator? I reviewed the specification of the TV microcontroller. The OSD related registers are allocated in 8051 external RAM (XDATA) space. These registers are named as MMR, memory mapped registers. During reset, all internal RAMs and registers are reset to default value as 0x00, 8051 XDATA space is in random state because internal reset circuit will not reset external memory. The specification does not mention it, because it is a common sense. I tried to reset the registers in the startup procedure. The problem was solved. I realized that was the root cause. Because the content was random after system resets, the occurrence was unpredictable, too. Finally the project was approved by the QA department.

As the integrated features and volume of registers are growing, more and more registers have to be allocated to XDATA space. And these registers contain random values after system resets. Developers must reset explicitly in system initialization.

After this project, I revised the whole source tree. All registers and variables in XDATA were explicitly written with zero or their default values. Sometimes writing 8051 XDATA space is a time consuming process. As an alternative way, the developers can leave it as is, however they have to make sure that the random memory will not influence the system performance.

No matter which language is deployed in development, C or assembly language, it is always a good practice to explicitly declare your registers and static variables in XDATA as default values, instead of leaving them to random values.

If some registers need to be reset as soon as system power on reset (POR), additional initialization code can be written in the start up code. For an 8051 C compiler (Keil), we can open startup.a51 to add assembly code to meet the requirement.