Regarding Flash Programming for the FRDM-A-S32K144N

[Fukuda]

I was debugging using the FRDM-A-S32K144N when the following symptoms occurred:

* Unable to write to flash memory.
* Since the write failure, the power LED and reset LED have remained constantly lit.

I attempted recovery by performing the following steps:

1. Tried writing to the flash memory by unplugging and replugging the USB cable while holding down the reset button, aiming to catch the window before the infinite loop started.
* Attempted this dozens of times but was unsuccessful.

2. Connected the USB cable while holding down the reset button to enter bootloader mode.
* Flashed "BOOTUPDATEAPP_Pemicro_v111.SDA".
* Then flashed "MSD-DEBUG-EVB-S32K144_PEmicro_v125.SDA".
* The situation did not improve.

3. Attempted flash recovery using "Kinetis_Recovery_Utility.exe".
* Unplugged and replugged the USB cable several times, but the process did not complete.

I am unsure what to try next.
If anyone knows how to restore the board, could you please advise me on the procedure?

[Robin_Shen]

Hi Fukuda,

I don't have the newly released FRDM-A-S32K144N development board on hand, so I haven't tested it myself. If you aren't in a rush, I can help you troubleshoot the issue now, and then perform tests on my end once I receive the board—which I expect to arrive in mid-October.

After plugging the cable into the J1 USB Type-C port, please take a photo of the top side of the board and share it with me.
I am not sure which two LEDs you are referring to, as the SPF-96556_B.pdf document only lists D5 (Red) and D4 (Orange).
If D4 is lit, it indicates that the onboard OpenSDA debugger is functioning correctly. However, if D5 is lit, it indicates that the S32K144N is in a reset state (The RESET_MCU signal may go low); please use an oscilloscope to observe the signal and check for the frequency of periodic low pulses. 

Additionally, I am unsure what program was previously flashed onto the S32K144N. If it is a blank chip and the RESET_MCU signal shows periodic high-level pulses with a period of ~118µs, you can recover the MCU by executing a "mass erase" command via the SWD/JTAG debug interface.

Since the onboard debugger is provided by PEMicro, it is recommended to download the latest "USB Multilink Resources Installer" from the "Support & Downloads" category of the "Multilink Debug Probes". After installation, open PEFirmwareConfig.exe located in C:\PEMicro\Multilink_Resources to check the firmware version. Select Hardware Type: Multilink ACP Embedded - OnBoard ARM Debug Interface  Then, check for available updates.

It appears you have already refer to the discussion "S32K144 D2 RED LED is ON always". Please note that the Kinetis_Recovery_Utility (Version 8.17) previously provided on the PEMicro website did not work correctly; the Kinetis_Recovery_Utility (Version 1.06)—which I uploaded as an attachment in that discussion—works properly.

When using the Kinetis_Recovery_Utility, It is recommended to keep the PEMicro debugger powered on and repeatedly power-cycle reset only the S32K chip.
If you have an external debugger like the Multilink connected to the J3, you can repeatedly plug and unplug J1 to cycle power to the S32K144N while keeping the external Multilink active.
However, if you do not have an external Multilink and are relying solely on the onboard OpenSDA debugger, the design of the FRDM-A-S32K144N presents some inconvenience. Jumper SJ10 is not as convenient as J107 on the S32K144EVB for repeatedly cycling power to the S32K144. I am not certain whether repeatedly pressing SW2 alone would allow the Kinetis_Recovery_Utility to successfully halt the S32K144N at the right moment.

Best Regards,
Robin