I bought a devkit-MPC5748G and after 5 minutes of testing, while loading an hello world code I erroneously pressed the RESET button.
S32DS studio now returns a reset escalation error and the board seem bricked like this:DEVKIT-MPC5748G is in reset state
I searched a bit, read the forum, found clues like this: https://community.nxp.com/thread/444748?commentID=877631#comment-877631
How can I proceed to unlock it, only with a PC and a micro USB cable ?
Is it really impossible to unbrick this $40 devkit without a $400 probe ?
I have a bad information for you. With almost 100% sure, you bricked your device and there is no possibility how to unbrick it back. Please check the thread below, my colleague described there the situation which had happened to you.
To make sure, you can measure reset line and in case reset line is always 0 after power on reset, your microcontroller is "dead" and it is impossible to unbrick it at all.
I took us 10 weeks to be delivered, and 5 min to brick it, the ratio is not good at all... especially for a development kit where errors are part of the game o_O
I will check the reset line to be sure but I'm not very optimistic.
If NXP can not refund, I may plan to look elsewhere for more reliable products :smileysad:
I've killed an MPC5748G (on my own board) by turning off power during programming (oops), and had to swap the BGA chip to recover, as even an external programmer had trouble connecting. So I think it's unrecoverable AFAIK if the reset line is not toggling. Note in some cases i had to do a careful power-cycling/connect with debugger timing to escape a reset escalation. If you haven't fully bricked the device it may need some experimentation to escape the reset escalation?
If you are ordering dev-boards get a few of them - if they are $40 it's cheaper than the chip itself in qty 1 anyway. The root cause (mentioned in other thread) is that the chip (by design) sees the corrupt data as a possible attack perhaps, so just locks itself out.
There are two points, which are absolutely independent. First one is Reset escalation, second one is the state when reset is always 0 after power on reset.
If there is the reset escalation, debugger is able to connect to the microcontroller. PEMicro can do this without any user intervention, Lauterbach has feature called Halt Core at power-on reset.
If you have any other question, please feel free to write me back.
Hi, Here is the another same problem with this kind of Issue. I am using S32 design studio and openSDA debudder to dubug sample application. It worked for 2 3 hours and after that the board is giving problem to load the programme. It is stucks at verification of block. have a look at screen shot. Connection from "127.0.0.1" via 127.0.0.1 Copyright 2017 P&E Microcomputer Systems,Inc. Command Line :C:\NXP\S32DS_Power_v2017.R1\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_22.214.171.124709281658\win32\pegdbserver_power_console -device=MPC5748G -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=OPENSDA -speed=5000 -resetÌ CMD>RE Initializing. MPC574xC Device detected. Target has been RESET and is active. CMD>CM C:\NXP\S32DS_Power_v2017.R1\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_126.96.36.199709281658\win32\gdi\P&E\nxp_mpc5748g_1x32x1520k_cflash.pcp Initializing. MPC574xC Device detected. Initialized. ;version 1.05, 06/26/2017, Copyright P&E Microcomputer Systems, www.pemicro.com [5748G_6080k] ;device NXP, MPC5748G, 1x32x1520k, desc=CFlash ;begin_cs device=$00F90000, length=$005F0000, ram=$40000000 Loading programming algorithm ... WARNING - Selected .PCP file has been modified. CRC16 = $5A63 Done. CMD>VC Verifying object file CRC-16 to device ranges ... block 00FA0000-00FA0007 ...
Thank you guys ! I did check at the oscilloscope. You spoke about the reset line (here and there DEVKIT-MPC5748G is in reset state). I choose to scrutinize the MCU-RSTX pin, but I don't know if it is the right one...
Nevertheless, this pin is perfectly alive on the remaining functional board but is desperately flat and null on the broken one
If I didn't mistake, I have a brick !
Is this issue a design problem of the board or the CPU ? Could we hope to solve this with a better design of a custom PCB, or is it a feature/bug of the micro itself ?
this is neither design problem nor CPU problem, but this is chip security feature. As Colin wrote above: The root cause (mentioned in other thread) is that the chip (by design) sees the corrupt data as a possible attack perhaps, so just locks itself out.
We have already reported this to S32DS team and in new S32DS release, there should be "fix" which ensures, that HSM blocks will not be included to memory mass erase.
Sorry for making you repeat :smileyhappy: Nonetheless, all these posts stitched together make a clearer big picture.
Please excuse my slowness to understand, partially due to my newbietude on such professional MCUs.
Thank you everybody for you explanations, I'll wait for the next release of S32DS.
Thanks for the clarification! The PEMicro pops up a "device may have entered reset escalation, power cycle board" message sometimes. Is there something I need to enable to automatically solve this?
I had mentioned this to Clement as I was getting the same error message in both cases it seemed (the one where it was recoverable, and the one where it isn't). It's worth nothing I have a very oddball hardware design as it's part of a security validation suite, so there is some differences w.r.t. the power supply on the board that can probably cause reliability issues.
I forgot to mention this point. S32DS sometimes shows this pop up windows, but it is often false positive. It means that microcontroller is not in reset escalation, but S32DS debugger warns you, that it could be in reset escalation state. This probably caused by that reset line is in 0 (in reset escalation is reset line 0 after some toggling), but in the second case, reset line is always 0 (without toggling).