It is problem regarding HSM and double bit ECC error in HSM memory area. Customer should avoid reset or power supply failure during the flash is erasing or programming. Please read the comment from Lukas Zadrapa.

I started using the DEVKIT-MPC5748G, successfully tried to compile,flash and debug the simple samples with the S32 Design Studio and ran

successfully through the mini tutorial to create the blinking LED application

with the Processor Expert. Then I modified my existing MPC5643L code,

flashed it - and got immediately stuck! Soon I found the problem in the

source code but no way to connect to the board anymore in order to flash

the corrected code...

Googling brought me soon to this and the related threads and this was mosthelpful to understand the situation of having an either bricked MCU or adestructive reset after reset escalation. Using my scope I could provewithin a few minutes that I was in the lucky latter situation. However,how to recover from that situation? The threads gave the right hints but I didn'tfind a to-the-point recipe what to do concretely. Here, I want to fill this gap.

The DEVKIT has an on board JTAG debugger, which is not capable to connectto the MCU any more ("Cannot put the MCU into background mode" orsimilar). The explanations given in these threads make it probable thatthe connection has to happen before we reach the destructive reset, i.e.after power on and during reset escalation. This is a time span of about300ms.

On the DEVKIT the debugger is normally turned on together with the MCU.

And it's simply impossible to first startup the debugger and then issue the

connect to target commands within 300ms. Once the debugger is ready to

operate the MCU is again in its destructive reset.

I connected a P&E Multilink Interface to the DEVKIT's JTAG connector. Thisdecouples debugger startup and powering the MCU.

Connecting the P&E Multilink Interface: The colored wire in the JTAGribbon cable belongs to pin 1 on the PCB; a small "1" is printed on thePCB close to the connector. It doesn't matter that we have two P&E USBdebuggers connected simultaneously to PC: The command line of the debuggerserver will address to the right one.

Next problem: At the beginning I had mainly used the debugger through theS32DS Eclipse interface. This means a strong delay between clicking thedebug button and the debugger making the connection to the target. All of this

takes much more than 300ms. Maybe it would be possible to first start the

debugger, count till three and then power on the MCU, but one would be very

lucky to succeed using this weak timing strategy.

Therefore I decided to use the debugger on the command line. Starting theserver involves an immediate attempt to connect to the target. Thestrategy: Type the command line and hold your finger above the enter key.Then plug-in the USB wire to the DEVKIT at the same time you release yourfinger.

Already in my second attempt the technique succeeded and I got connectedto the board.

Many people may have bought their DEVKIT because of it's amazingattractive price and they won't have bought an additional Multilinkdebugger, which costs much more on its own then the entire DEVKIT includingthe debugger. Next step was to find out how the same can be achieved withthe on-board debugger.

A view at the schematics revealed that powering of the debugger and of theMCU is indeed decoupled though the jumper to select either USB or external12V powering. Two possible strategies:

plug in the DEVKIT, enter the start server command line (finger still above

enter key), then switch 12V supply on and hit the enter key at the same time.

2) The jumper for selecting the power supply for the MCU can be abused asswitch to power the MCU on or off: If it is detached the MCU is unpowered(but the debugger still is through USB), if it is attached in positionselect-USB-power then the MCU is powered. Strategy 2) is identical to 1)except for not switching the external 12V supply but using the jumper asMCU power switch.

I tried 2), and since handling the jumper as switch is a bit tricky ittook me this time five or six attempts to get the connection. But still anacceptable way of doing.

Now we have the debugger connected to the MCU but the SW fault leading tothe reset escalation is not fixed. We can first use the debugger toidentify the problem but eventual we need to use it to flash a corrected pieceof software. Getting here you should have a proven *.elf file at hand,take any previously compiled, still success build. There are two ways toflash this binary and/or step through the still flashed, faulty software:

1) In S32DS, duplicate and modify your Debug Configuration normally usedfor flashing. By default, the debug configurations start the debuggerserver every time you click on debug. Our server is already started and weneed to modify the configuration such that it not starts a server andconnects (through a TCP/IP socket) to our already started server.

2) Open a new shell window and start the debugger client from the commandline. Issue the debugger commands to start the software, step through itand finally the flash command to replace it with the proven, wellworking binary you have at hand.

I only tried 2) but 1) is likely straightforward, too, as the S32DS GUI exposesthe according elements to click.

After flashing the proven binary the board is back in the normal state.The debug server can be disconnected and stopped, and the S32DS can beapplied as normally.

Here are the command lines, you need to perform the steps of the recipe.(<installDir> is the root directory of your S32DS installation, thefolder, where Cross_Tools, Drivers, eclipse and more can be found in):

1) Command line to start the debugger server if the P&E Multilink debuggeris used:

The following commands are submitted from the command line of the debuggerclient after the debugger server was successfully started and got theconnection to the board and after the debugger client has been started:

4) Connect the client to the debugger server:

target remote localhost:7224

5) Commands to initialize the debug session. (These commands have been takenfrom the console window of the S32DS debug session. I don't know whetheror to which extend they are essential):

6) If you want to step through the buggy, still flashed code then you needto load the related *.elf file to have the symbols and references to thesource code. Note Windows users, <pathToElfFile> uses either slashes ordouble backslashes: