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

[Fukuda]

Hi, Robin.

I apologize for the significant delay in my reply.

I have attached a photo of the board to this post.

Unfortunately, I do not own an oscilloscope, so I was unable to verify the frequency.

I tried using PEFirmwareConfig.exe, but the FRDM-A-S32K144N did not appear in the device list; I will continue to look into this.
I will also continue attempting to use the Kinetis_Recovery_Utility.

I apologize for the lack of significant progress since my last post.

Best Regards,
Fukuda

[Robin_Shen]

Hi Fukuda,

Thank you for your update, and no worries about the delayed response.

I just returned from vacation. Unfortunately, the FRDM-A-S32K144N board I ordered has not arrived yet, so I am currently unable to perform any testing.

Although I haven't received the FRDM-A-S32K144N yet, I tested the onboard debugger using the FRDM-A-S32K344:
PEFirmwareConfig.exe successfully detects the onboard debugger, as shown in the image:

Unfortunately, Kinetis_Recovery_Utility (Version 1.06)—the version capable of successfully halting the MCU—does not detect the FRDM-A-S32K344's onboard debugger.

While Kinetis_Recovery_Utility (Version 8.17) does detect the FRDM-A-S32K344's onboard debugger, it fails to halt the MCU, as I mentioned previously.

Please wait while I consult PEMicro technical support regarding the issues currently encountered with Kinetis_Recovery_Utility.

Do you happen to have an external PEMicro debugger, such as a Multilink Debug Probe? I recall that Kinetis_Recovery_Utility (Version 1.06) can be used with external Multilink Debug Probe.

Additionally, have you tried the "Emergency Kinetis Device Recovery by Full Chip Erase" feature in S32DS that I mentioned in the "S32K144 D2 RED LED is ON always" thread?

[Robin_Shen]

Also, have you tried the workaround mentioned in "Solution to FRDM-A-S32K144 and FRDM-A-S32K144N not detected during initial USB-C connection"? Even though I see the orange D4 LED is lit on your FRDM-A-S32K144N board, I still suggest trying the other workarounds. This is because the FRDM-A-S32K144N I ordered isn't expected to arrive until next week for testing.

[Robin_Shen]

I just received the FRDM-A-S32K144N and tested it.
Bearing in mind the issue mentioned in "Solution to FRDM-A-S32K144 and FRDM-A-S32K144N not detected during initial USB-C connection" I used a USB-A to USB-C data cable.

PEFirmwareConfig.exe did not detect any Multilink hardware. This differs from the test results for the FRDM-A-S32K344; I apologize for misleading you earlier.

The D4 LED is lit orange, indicating the OpenSDA status is normal, and the device appears in Device Manager.
In Kinetis_Recovery_Utility (Version 1.06), selecting "Show Hardware" and clicking "START" reveals the OpenSDA device.

After selecting the OpenSDAUSB device and clicking "START," the following appears:

Communication via SWD
Cable Version is 119
Continuously attempting to halt processor.
Please try power cycling your board until this operation is successful
Success. Processor halted.

[Fukuda]

Hi, Robin.

Thank you for your reply.

Unfortunately, I do not own an external PEMicro debugger.

I have also tried the "Emergency Kinetis Device Recovery by Full Chip Erase" function in S32DS multiple times, but all attempts failed.

Since the FRDM-A-S32K144N is recognized by the PC, I have not tried the "Solution for when FRDM-A-S32K144 and FRDM-A-S32K144N are not detected via USB-C connection."

Just to clarify, does "power ON/OFF" in the Kinetis_Recovery_Utility refer to unplugging and replugging the USB cable?
Even after unplugging and replugging the USB cable, the process did not proceed past the message: "Please try power cycling your board until this operation is successful."

Best Regards,
Fukuda

[Robin_Shen]

I connected an external J-Link Plus to the onboard S32K144N via J3 and erased the chip using the `unlock kinetis` command in J-Link Commander.

Now, observing the J9.5 RESET_MCU pin with an oscilloscope, I see a square wave signal with a period of approximately 120 µs and a high-level duration of about 660 ns.

Regardless of whether I hold down SW2, the onboard OpenSDA, in conjunction with Kinetis_Recovery_Utility (Version 1.06), successfully halted the MCU:

At this point, the periodic pulses on the J9.5 RESET_MCU pin stop; after closing Kinetis_Recovery_Utility, the new program can be downloaded within S32DS v3.6.11.

Have you previously programmed the S32K144N?

Are you using a USB-A to USB-C data cable?