Hello everybody! I've made two automotive related projects, one very simple based on S32K118 and second looking nice...
...but in fact also simple. I'm using S32 Studio v2.2 with SDK 3.0, Segger J-Link and communication via SWD interface. During programming I've lost communication with first S32K118 and despite of many attempts I was unable to connect with MCU. After MCU replacement everything was working fine, no any problem occured at debug sessions. It seems I've blocked it but I don't really understand how. Just a few hours later I had exactly the same scenario with S32K144 but now I'm in trouble due to lack of spare parts.
There are two main questions, what did I wrong and how to avoid such failures? As I already figured out, it is not possible to unlock bricked MCUs or am I wrong?
About two years ago I did another project based on S32K144 and I remember I had weird problems with first programming of new MCUs. It was difficult to flash it but finally I did it and after first programming no any other flashing related problem occured, however I didn't lock any MCU at that time. I'm really sad due to S32K144 failure because I have only one piece, now whole project is down.
Hello @krzemowy,
Can you please use J-link commander and follow this thread:
https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227
Thanks,
BR, Daniel
Hi Daniel,
thanks for reply.
I tried to communicate with MCU via J-Link Commander with no success, as on screenshot.
I didn't check with oscilloscope if RESET line is driven properly, I'll do it tomorrow(lack of time, sorry).
I see two interesting things:
BR, Witold
Hi @krzemowy,
You have to use the "connect" command first, as suggested by the commander.
Then, it will ask you a few questions, like the speed of the connection etc.
BR, Daniel
Hi Daniel,
I tried to use "connect" command, without success. I don't have a screenshot from J-Link commander window but I can describe what was shown. After command was issued, J-Link tried to connect, figured out the device is secured and attempted two times to unsecure, after these two failed attempts command execution was finished.
In the meantime I bought Multilink interface and one FS32K144HAT0(I see I was really lucky to get it). First I tried to connect and unsecure old MCU but it was not possible. I replaced MCU with a new one, then I tried to connect with Multilink and new empty project in S32 Design Studio - keeping my fingers crossed - and I connected successfully. Then I switched to final project, tried to connect and................ I've got a one more brick............. Just by one click on Debug icon. I've checked startup, linker and output files and found nothing wrong. I'm getting more and more disappointed, I've lost one more expensive and nearly impossible to get MCU and I still have no idea why. I've checked supply voltage, no any significant noise nor spikes were found.
I attached both project. The first one, 'unbrick' is an empty one used to first attempt to communicate, second one is a target project. Please look, maybe you will find something.
BR, Witold
Hello @krzemowy,
This very issue was discussed in the thread I was referring to:
https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227
Please connect the reset_b pin to VSS and power cycle the MCU.
BR, Daniel
I'm sorry I forgot to do it. In the meantime I let J-Link go, now I have a Multilink.
Here is a result:
In another words, MCU is still locked. By the way, without reset line pulled permanently low from time to time I was being informed the device is secured and asked if I want to unsecure - unsuccessfully.
Hello @krzemowy,
PE Micro does not show what is the state of the MDM-AP status register.
It only informs about the state of the security.
Either Segger ot Lauterbach can be used to read the status register.
Were the MCUs partitioned for CSEc? If so, mass erase is blocked by the CSEc engine.
BR, Daniel
Hi @danielmartynek,
we have Lauterbach at work, I think I'll be able to use it but not at the moment. Most likely it will be possible in April.
MCUs we're not partitioned, no any security feature was used.
BR, Witold
I have some clue. At beginning, I created a project(TPM_emulator_old in attachment) on S32K144EVB-Q100 devboard and then changed MCU type in project to S32K118. After attempt to debug in target HW I've bricked MCU. Then I replaced MCU, created new project(TPM_emulator in attachment) exactly for S32K118 and it is working. There was a similar scenario with S32K144. By first, project was created on devboard, then MCU setting was changed from S32K144_100 to S32K144_64 according to pinout and after attempt to debug MCU was locked. After MCU replacement I tried to debug an empty freshly created project and everything was fine. When I tried to debug a target project I've got a MCU locked.
It may be just a coincidence but it is confusing...