topic Re: S32K3 bricked, unable to debug in S32K

S32K3 bricked, unable to debug

Greavesinator85 — Tue, 26 May 2026 11:45:09 GMT

Hi, I've been trying to use AB_SWAP firmware for bootloading. I've not progressed the lifecycle or anything like that, and secure boot is not enabled. I am flashing one bank, and then performing an active bank switch using HSE. I was experiencing compounding reset reasons

Bit 0 (0x0001): Power On Reset
Bit 8 (0x0100): FXOSC Failure
Bit 15 (0x8000): System Clock Divider Failure

After experimenting with switching the clock to FIRC before the bank switch reset call, I have not been able to access my MCU with JLink.

I've tried connect under reset, running in a loop and power cycling etc. Is there any boot configuration via pins I can use to keep it in a known state, or factory reset tools to recover this?

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: S32K358_M7_0
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "S32K358_M7_0" selected.

Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 27us
InitTarget() start
SDA_AP detected
Unlocking device if necessary...
Device is not locked. Proceeding without the unlock procedure.
Checking if debug access is already enabled...
Debug access is not enabled yet. Performing enable debug access sequence...
Debug access enabled
Checking if HSE firmware is installed...
HSE firmware not installed
Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode
Lock step mode enabled
InitTarget() end - Took 10.0ms
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000)
AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user
AP[4]: Core found
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 13us
InitTarget() start
SDA_AP detected
Unlocking device if necessary...
Device is not locked. Proceeding without the unlock procedure.
Checking if debug access is already enabled...
Debug access is not enabled yet. Performing enable debug access sequence...
Debug access enabled
Checking if HSE firmware is installed...
HSE firmware not installed
Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode
Lock step mode enabled
InitTarget() end - Took 20.5ms
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000)
AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user
AP[4]: Core found
****** Error: DAP error while reading AIRCR.
Error occurred: Could not connect to the target device.
For troubleshooting steps visit: https://kb.segger.com/J-Link_Troubleshooting
J-Link>

Re: S32K3 bricked, unable to debug

db16122 — Tue, 26 May 2026 12:52:11 GMT

Could not connect to the target device.? What kind of board you are using for programming?

Re: S32K3 bricked, unable to debug

Greavesinator85 — Tue, 26 May 2026 14:57:37 GMT

It's a custom board, but I have been using it for a few months so its not a hardware issue. Then its a J-Trace connected with SWD.

Re: S32K3 bricked, unable to debug

lukaszadrapa — Thu, 28 May 2026 06:13:25 GMT

Hi @Greavesinator85

No, there are not boot configuration pins on this device. I know that this could be a workaround on some other devices but that’s not the case of S32K3. It always boots from internal flash memory only.

Could you check the reset signal? Isn’t the reset asserted all the time? I was playing with JLink on my board and I got exactly the same error message when I kept the reset asserted during ‘connect’ command execution.

Regards,

Lukas

Re: S32K3 bricked, unable to debug

Greavesinator85 — Thu, 28 May 2026 09:15:29 GMT

Hi Lukas,
I scoped it out. Reset seems to be flickering intermittently without any JLink operation. It holds high during the connect, and then resets as part of the normal connection procedure. I tried with the Reset pin strongly pulled high to avoid any issues there but still I get the exact same issue

Re: S32K3 bricked, unable to debug

Greavesinator85 — Thu, 28 May 2026 09:27:12 GMT

To clarify. A 50us reset pulse is being asserted every 30ms, with or without the JLink connected

Re: S32K3 bricked, unable to debug

Greavesinator85 — Thu, 28 May 2026 14:26:38 GMT

After 6 hours of leaving the board with the oscilloscope connected, I noticed the reset pattern had stopped. I was able to connect and erase the board. I'll continue with my development cautiously.

A theory is that the code I added to switch HSE partition included a clock switch, from FXOSC + PLL to FIRC to resolve some reset issues. I guess not gracefully closing the GMAC peripheral that was using the PLL, or not waiting for it to complete shutdown was causing instability that was then exacerbated during clock init entering some kind of reset cycle.

Re: S32K3 bricked, unable to debug

lukaszadrapa — Fri, 29 May 2026 14:09:45 GMT

I got new information from my colleague. If you meet this problem again, try following commands:

erase

Do not use 'connect' before that. After 'erase' command, it will ask you to establish the connection. And then it will erase the flash and while no code is executed.

If it does not work, you can try to use JTAG mode instead of SWD. It looks like this can also make a difference.

Regards,

Lukas