OMAP-L138 ESD compatibility IEC 61000-4-2

Hi,

we using OMAP-L138 in our medical device and we facing problems durign the ESD test (IEC 61000-4-2). We tried the modifications (hw/sw) stated in the errata but without success. I would say I didn't noticed any improovment.

The PCB with the CPU is mounted in a metal chassis and a direct discharge to the chassis stops the CPU. Only reset or power cycle can restart the CPU. It is very sensitive even 2kV makes problem (we need 6kV). We use a simple test sw which boots up from SD card and togles a GPIO wich is connected to a LED. The sw runs in the internal ram and doesn't use DDR ram at all but it seems that that the DDR interface is the most senitive. If I indirectly couple transient field (with passive probe) around the clock circuitry the sw only stops for max 1sec but than it runs again.

Please if somebody has real life experience share it.

Have TI a reference designe which acually passed an IEC 61000-4-2 ESD test?

Best Regards

Peter

Hi Peter

I am not aware of TI doing a reference design for OMAPL138 with IEC test verification, however, the LCDK board was implemented with all good practices recommended in the ESD usage note for the device.

We have several customer ramp to production with the documented recommendations on increasing the immunity achieving anywhere between 6KV - 12 kV depending on board/application designs.
 

Hopefully someone in the customer community might also vouch for what I stated above.

I would be interested in understanding "how" you tried the hw modifications?

1) Does your board under test already follow the recommendations on routing the input clock traces as close to the processor, in the inner layers and adhere to the DDR routing specifications in the datasheet?

2) Does your board already has an external oscillator with the recommended slew rate or did you try to retrofit it after original design with a crystal (any blue wiring etc to fit an ext oscillator might or might not work , depending on the blue wiring work and antennas created)

3) Please make sure that you followed the DDR REFCLK disable workaround as per the latest silicon errata usage note (the previous version of the errata had a partial sequence)

4) Any visuals of the board? Is it a single board or multiple boards with connectors etc?

I will also point this thread to our system ESD experts to see if they have more questions on your testing methodology etc.

Regards

Mukul

hi Mukul :

I have the same problem, and somebody encounter the same problem also.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/99038.aspx

I have used a External 3.3V Clock Source,and use a resistor voltage divider. But it is no effect.

I want to know that the CLKMODE bit in PLLCTL is set to 1 or clear to 0,when use a a External 3.3V Clock Source.

Wheather the CLKMODE bit need to be set??

Thank you very much.

Hi Haohua

Sorry for the late response. CLKMODE bit setting is a don't care, but you can set it to 1 to match the documentation (not using internal oscillator/crystal).

The post you linked is old and as far as I remember it did get resolved and if I recall they were able to use the ext oscillator with a fast slew rate/rise time and saw improvements.

It is important that you have the ability to test the external clock source + resistor divider implemented on a board (as a change in layout), if you are testing a board with hardware mods made (changing a crystal to blue wire in a ext clock source), the hardware mods have to be very well done to make sure there are no long leads, hanging wires that can act as antennas etc.

Hope this helps.

Regards

Mukul

Hi Mukul

Thank you for the quick response. It is good to heat that others had achieved the required immunity level, but I hoped that if TI aware of the problem and they design an eval board than they also verify it and report the results.

Anyway I ordered the LCDK board and will do the test myself. I did the testing with the LogicPD eXperimenter Kit but it has the same ESD immunity issue.

Answers to your questions:

1) We used Xtal instead of clock oscillator but otherwise we did the layout according the recommendations.

2) I could retrofit the xtal with a clock oscillator therefore no blue wiring was needed. I used the FXO-HC735-25 from Fox Electronics. The measured rise/fall time was about 2.6ns.

3) We implemented the same sequence as stated in the errata, although we cannot find out what are in the Set_DDRPLL_150MHz() and in the Set_DDRPLL_150MHz().functions exactly. We use AISgen to set up the PLLs DDR etc. and in the bootloader main function we implemented the rest.

4) It is a single board (8 layers), there are connectors but it is failed without any connections.

I try to understand what happening with the CPU during the ESD event. As I wrote in my last post I can observe two different behavior:

a)      If I couple the pulse (indirectly) into the clock side or even directly onto the CPU I can observe only a short pause and than the CPU continuous the operation. I suppose that the PLL is disturbed and should lock again and until it is locked the CPU is in halt. In this case I saw some improvements in immunity. With the clock oscillator it is harder to reproduce this event.

b)      If I couple the pulse into the DDR ram 2-3cm away from the CPU then the CPU stops and cannot recover. It seems that the PLL stops because I cannot measure the DDR clk output.

Can you explain the two failure modes? What can cause the PLL to stop in case b and why can it recover in case a?

 Regards

Peter

Hi Peter

Peter Krammer said:

but I hoped that if TI aware of the problem and they design an eval board than they also verify it and report the results.

Anyway I ordered the LCDK board and will do the test myself. I did the testing with the LogicPD eXperimenter Kit but it has the same ESD immunity issue.

The LogicPD EVM was designed prior to uncovering this issue. LCDK board does try to put some good practices in play. We have not ourselves tested the LCDK for IEC testing etc. The intent of these boards is primarily to be software evaluation platforms and to some extent have reference-able elements that customers can copy.

We did make mini boards with very little components (flash , external memory, ext oscillator + SoC) to test out the external oscillator work around and it worked well.

Additionally ESD issues are truly "system" issues and while OMAPL138 has additional sensitivity due to the 1.2V CLKIN/OSCIN, we have had situations where all mentioned recommendations were followed and still no improvements were seen because of some other components or deficiency on the board. E.g in one scenario it was touch screen controller part, and how the AD0/1 lines were tied off to create an I2C address. The noise was coupling to power planes through this chip , not OMAPL138 etc.

Peter Krammer said:

3) We implemented the same sequence as stated in the errata, although we cannot find out what are in the Set_DDRPLL_150MHz() and in the Set_DDRPLL_150MHz().functions exactly. We use AISgen to set up the PLLs DDR etc. and in the bootloader main function we implemented the rest.

Essentially these will just be the configuration functions to configure the DDR registers and PLL1 to run at the desired frequency. The init can be done via several ways, some might have GEL file (for initial development), uboot or as in your case using AISGEN that is why the usage note tries to show this in generic fashion. The key is to make sure that you disable REFCLK as listed in the usage note, to see if it buys you additional robustness from a DDR standpoint.

Peter Krammer said:

Can you explain the two failure modes? What can cause the PLL to stop in case b and why can it recover in case a?

Unfortunately hard to say. Usually in other customer systems we found the side with OSCIN etc to be the most sensitive to ESD zaps. Failures would usually result in CPU halting etc (glitches propagating to mess up the clock logic internally), additionally in most cases the program code executing from DDR would stop executing, as the DDR internal logic can get messed up (read/write pointer corruption), causing CPU to fetch garbage code from invalid locations etc. Peripherals directly driven by auxclk were additionally more sensitive too.

I assume the test program running in scenario A & B is the same?

To further confirm that PLL has stopped working, perhaps you can also probe the OBSCLK with a divide down value from one of the PLL SYSCLK outputs?

Hope this helps.

Regards

Mukul