MPC5746C enter reset escalation

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

MPC5746C enter reset escalation

2,962 Views
wenping
Contributor II

Hi there,

      I accidentally stopped the programming procedure to flash of MPC5746C. Then i failed to connect to the device all the time, with the window pop up  and the LED indicating reset is always on.

      The OSJTAG is OK, I can use it to connect to other devices.

       I had search answers about this problem in this community, and can not find out a solution to revive the device. 

      If there any possible that this device can be revived? If yes, how? If not, what should i avoid to count this problem again, because i need to write a bootloader for this device. I'm concerned that this problem will happen again if i can not program flash correctly. In fact, I still have no idea why this can happen....

      Thanks.

Labels (1)
6 Replies

1,844 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

Do you see constant reset signal on reset pin?

This issue has been discussed many times here.

1. If you do see permanent reset (measure it via oscilloscope please) then the device is bricked and cannot be recovered.

2. If you see real reset escalation you will see reset line toggling at start. (this is in most cases cause by SWT) and the device can be recovered.

But interrupting flash operation can lead only to first scenario. (bricked device)

If you wan to avoid this situation do not work with HSM flash block.

pastedImage_1.png

The lost of power will lead to multibit ECC faults and this is recognized as security attack by HSM. Which will lead to lock of micro by HSM module.

Peter

0 Kudos

1,844 Views
wenping
Contributor II

Hi, Peter, Thanks for your reply.

I had measured the reset pin with a oscilloscope, and the picture is attached below. 

新建文件1.jpg

 So, is this the first scenario you described? 

0 Kudos

1,844 Views
petervlna
NXP TechSupport
NXP TechSupport

Ok,

good for you is that device is not bricked.

You have only reset escalation. I can see 16 resets which corresponds to default value 0xF for reset escalation register.

This is caused by unhandled SWT.

You have to connect your debugger before any code can be executed. (or until next reset occur)

This time is very short - few ms.

Some debuggers (like lauterbach) include half core on power-on reset feature.

For the less advanced debuggers you can use workaround:

1. Connect with debugger within 300ms

2. Hold external reset, Power the board, attach with debugger, do break, and release the external reset.

You can search for solution on our forum. I have described it in at least 5 threads:

https://community.nxp.com/message/965111?commentID=965111#comment-965111 

Peter

1,844 Views
wenping
Contributor II

Good News, My friend, Both the three board are revived :smileyhappy:

I flash the core0.elf file from example project "MPC5748G-Serial_Bootloader-GHS614" into the MPC57746C with a 

reset escalation problem. And then the reset escalation problem disappeared. Then I can successfully flash the elf file of my own project into the chip. Power down and then power up, the LED blink :smileyhappy:. But I still do not know why. And I will continue to check it, if I found answer, I will write to you.

Thank you very very much for your help.

Best wishes to you.

0 Kudos

1,844 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

From the plot you have shared I will bet my dolar on unhandled SWT after reset.

You have to service it in startup as default timeout is 20ms.

Peter

1,844 Views
wenping
Contributor II

Thank you for your reply!

These days I had tried many times as your advise, And several times I can successfully go into Debug_RAM mode, but when i choose to  download flash,  it says "Interrupt command received. Halting execution" and the progress bar stay at 99%, and the S32 Design Studio collapsed. I have three board with the  same problem. 

  pastedImage_1.png

The first board got this trouble because  I accidentally interrupt the process. But I do not know why this happened to the second and third board.

here is the memory i used in the MPC5746C_flash.ld

MEMORY
{

flash_rchw : org = 0x00FA0000, len = 0x4
cpu0_reset_vec : org = 0x00FA0000+0x10, len = 0x4
cpu2_reset_vec : org = 0x00FA0000+0x04, len = 0x4

m_text : org = 0x01000000, len = 256K   //one time with org = 0x00FC0000,
m_vectors_ram : org = 0x40000000, len = 0xC00
m_data : org = 0x40000000+0xC00, len = 192K-0xC00
}

Is there any problem with the setting?

I just have another two virgin chip now, and i can't flash these two until I find why this happened :( .

0 Kudos