OMAP-L138B, how to decode the top marking

Hi Michel

Due to security reasons, we do not publish this information online. This might be shareable selectively under proper constrains. If you need additional details, you can send me a private message over E2E with your email id, and I will connect you to our quality team. 

FWIW, the lot code you have is from Nov 13. 

Regards

Mukul 

Hi Mukul,

Thanks for your reply. I wanted to send you a private message so you could contact your quality team but I don't get an option to start a new conversation in your profile.

Regards,

Michel

Hi Michel,

Send a friend request to Mukul to start a conversation.

You can make conversations only with your TI E2E's friend lists.

Hi Michel

As discussed offline, we  now have your lot trace information , forwarded by our regional field and quality team and the central quality team is looking into this. 

OMAPL138 device has been in production for several years, so I will be very doubtful that the failures you are seeing are due to a "bad" lot. For the lot-trace you mentioned we have no previous reports of any issues. 

So I would like to focus a bit more on your actual failure symptoms, and see if we can find some additional clues on where in the system  there might be a marginal behavior causing the failures. 

This will be in parallel to whatever quality team might recommend to enable you to send some "bad" units for additional testing. 

What I have so far is following

about 2/3 of the CPU’s crash when performing certain operations in software. We are currently investigating which instructions on lower level trigger the kernel crash. The problems result in instability and crashes when the processor is cooled or heated.

the crashes we are experiencing occur at approx. 22 degrees Celcius and more often when temperature rises (40 degrees) and not often at low temperatures (-20 degrees).

1) Can you provide information on what is your OMAPL138 system comprise of , in terms of peripherals / modules in use , when you see the crash?

2) Any linux kernel failure logs? Any initial guess on what might be causing a failure from a software point of  view, internal memory , external memory?

3) I am assuming that even with failures being temperature dependent, you are always able to boot up properly? 

4) I hope you have cross-checked the errata, the only temperature sensitive silicon errata is the one on USB, and there we do expect failures to happen with temperature swings. These failures by its nature can be lot trace dependent. The issue is fixed on latest si rev 2.3.

5) You see temperature dependency, do you see any voltage/frequency dependency on failures?

6) Have you done any device swap experiments, to see if the failure follow the device or the board e.g, if you were to put a unit from the so called "bad" lot trace from a "bad board" to a previously "good board/system" , does the failure follow the device and the good board becomes bad?

7) Any changes in software, BOM or manufacturing between devices from "good" vs "bad" lots?

Regards

Mukul 

Hi Mukul,

I understood from one of my colleagues that we received an escalation form or something like that from TI and I think for now it's better to stick to one path to prevent miscommunication and double work. So for now I want to thank you for your support so far and if needed I'll contact you again.

Regards,

Michel