S12GN16 Flash data lost issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S12GN16 Flash data lost issue

554 Views
momo
NXP Employee
NXP Employee

Hi:

One of my customers is using S12GN16 now. They reported that a lot of chips (50+) failed to work recently. However, they said they have programmed and tested the products successfully on production line (with CyclonePro). Most of them were found by their customer and the others were found by themselves when they tested the products again.

 

We read out the data of all the failure chips and found that most of the Flash data was erased (the data unerased was not changed). The erased region is a single large area from the 1st address onwards or from the last address backwards or the whole Flash area. The boundary of erased region is not aligned with sector or block 

  

The following is the summary of the symptom and the test we have done. Unfortunately, we still can't find the reason of erasing and provide the solution to avoid this issue. Please help to provide some comments. Thank you!

 

  1. The Flash seems to be erased at sometime after the chip passes the programming and testing on customer's production line.
  2. The symptom will disappear if we reprogram the Flash
  3. The erased region is a single large area from the 1st address onwards or from the last address backwards or the whole Flash area. The boundary of erased region is not alligned with sector or block
  4. The MCU is unsecured in customer's normal product. It is very strange that for most of the failure chips, the security byte in Flash is still "unsecured"(0xFE), while other data around it is erased to 0xFF (it is the case when the 2nd half part of Flash or the whole Flash is erased). I have no idea which flash command or external signal can lead to this symptom
  5. Have reviewed customer's code and didn't find any flash driver or flash register access. The customer's code is very simple, only PWM,COP and LIN stack are used.
  6. Have tried to add Flash protection bits (0x3F) and fill all the exception entry with a loop function to avoid CPU running away. But the issue still exists after the software is modified
Labels (1)
0 Kudos
1 Reply

341 Views
lama
NXP TechSupport
NXP TechSupport

Hi,

I feel something wrong in the SW. It can somewhere lose program flow, usually incorrect COP processing, incorrectly processed interrupt,...which can cause program flow failure and the code executes out of incorrect addresses. Such a ode can do anything. Could I see the code? have you seen such a behavior excluding individual parts of the code? (You will start with one functionality and then add others step by step). If you it is necessary I can also have a look at the code. If it is confidential then you can create a "case" following this way https://community.nxp.com/docs/DOC-329745 . Just start the question with "Hello Ladislav" in order to direct it to me. Or you can zip entire project with password and send me a password in private message.

I see no HW issue from my experience. (I hope this case will not change my confidence :smileyhappy:)

Best regards,

Ladislav

0 Kudos