Why is S32K going to SRAM on reset?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why is S32K going to SRAM on reset?

842 Views
tim_smith_60b
Contributor I

Note: This is on a FRDM-PK144 evaluation board.

When I reset the micro, it appears to start execution at 1C00_01CCh.  This happens if I reset it in S32 Design Studio, or a different debugging program.  If I start a new debugging session, it starts at the correct place (PC is loaded based on the value at address 4h, with SP loaded from 0h), however if I issue a reset after that it jumps to the RAM location mentioned above (with a different stack pointer).

If I just use USB to only power the board (and don't attempt to debug), I don't see any signs of life (and the reset LED eventually comes on and stays on), so I would believe it's trying to run from RAM at this point as well.

Does anyone have any insight?  When I can actually get my code running, it runs fine.  Furthermore, it appears that 1C00_01CCh is loaded into PC right at reset, so I don't see how even if there was an issue with my code it could cause this.

Thanks

0 Kudos
3 Replies

601 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Tim,

debuggers usually initialize program counter manually after loading the code to RAM or flash. Even if the reset vector is not set correctly in a project, it may work when using debugger but it will crash in standalone mode.

First thing to check - what can you see at address 0x0 and 0x4 in memory window in debugger? Are there expected values?

For example:

pastedImage_1.png 

The PC and MSP is initialized as expected after reset:

pastedImage_2.png

Regardless of debugger you use, the code should be executed after power-on reset without debugger.

Regards,

Lukas

0 Kudos

601 Views
tim_smith_60b
Contributor I

Hello Lukas,

Yes, I'm aware of that, and I'm guessing that's why it works when I start a new session, but not afterwards.

That's actually one of the first things I double checked.  It does, indeed, have the correct values located there both when starting, and after a reset puts it in RAM.  It's also a bit confusing that RAM would even contain valid data after a power-on, but without a debugger hooked up I don't know for sure that that's what's happening.

I don't think this would be the case since the debugger is halting it right out of reset, but are there maybe any security features on the device that might cause this?

Thanks,

Tim

0 Kudos

601 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Tim,

not sure what's going on - could you send me your project, so I can test it here?

Regards,

Lukas

0 Kudos