IMXRT1064 Stuck in ResetISR

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

IMXRT1064 Stuck in ResetISR

637 Views
nelson18
Contributor II

When debugging with OPENOCD I am stuck in the ResetISR and cannot get past 

__asm volatile ("MSR MSP, %0" : : "r" (&_vStackTop) : );

I am starting from example projects with the example setup.

The thread ends up at 0x2020b4
signal handler called () at 0xFFFFFFF9
ResetISR()

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x0451:0xbef3, serial=00000000
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 1.2.0
Info : CMSIS-DAP: Serial# = 00000000
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 1 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x0bd11477
Info : [imxrt.cpu] Cortex-M7 r1p1 processor detected
Info : [imxrt.cpu] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for imxrt.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
[imxrt.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x0021aa58 msp: 0x20200fa0
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"

I have also received this line which is maybe more telling of a hardware setup issue?

"Cannot reset into entry when boot mode is 0"


This is a custom board

Bootmode is setup for 00 to use the fuses, which I believe should start from internal?


0 Kudos
4 Replies

577 Views
nelson18
Contributor II

I am using this SDK_2.13.0_MIMXRT1064xxxxA

Tried it with a segger j-link and get 2 break points found at 0x70002000 and then it crashes after 
stepping 1 time in the reset vector.

There is a post regarding the stack not being correctly initialized could this be the issue?

This is a custom new design board so the issue could be hardware related?

0 Kudos

603 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @nelson18 ,

What did you burn in the fuse?

What IDE and SDK do you use?

Can it switch to internal boot mode or serial download mode?

This command is to set stack pointer. Is &_vStackTop a legal address(at 0x70002000)?

Regards,

Jing

0 Kudos

594 Views
nelson18
Contributor II

The fuses should be default, I have not intentionally burnt anything into the fuses.
Just wanted to override the GPIO with default fuses.

SDK is built/downloaded from NXP for MIMX1064 and should be latest(will check when I'm in office)
I used MCUespresso with OPENocd connected to CMSIS-DAP device

Can it switch to internal boot mode or serial download mode? How do I check this?

This command is to set stack pointer. Is &_vStackTop a legal address(at 0x70002000)?
0x70002000 is the start of the program?, I think the stack pointer is somewhere in ram 0x20020000(0x20200fa0)
I am using the default program supplied by the SDK, maybe the linker script needs to be modified?

0 Kudos

574 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @nelson18 ,

Please refer to the system boot chapter to see what is serial download mode and internal boot mode. I don't know if your board has pin out the boot pins.

RT1064 internal flash start address is 0x70000000. After FCB and IVT, application start address should be 0x70002000. But yes, application start address also can in ITCM or DTCM. ROM boot or debug IDE can copy code to there. But the SP pointer should be initialized correctly.

 

Regards,

Jing

0 Kudos