Zixun LI

LPC845 strange debug behavior with IAR & J-Link

Discussion created by Zixun LI on Aug 1, 2018
Latest reply on Aug 3, 2018 by Felipe García



I met some strange behavior when debugging the LPCXpresso845MAX board with J-Link (v6.32i) and IAR 8.22, on board debugger is disabled by JP1.


I'm using the blinky demo, here is what I did :

1.Without the debugger the program run correctly, when debug session is launched, PC went to 0xfffffffc when SysTick exception is raised. In IPSR register exception number is 3 which is hardfault, but hardfault handler is not entered(hardfault handler address is in intvec and SCB->VTOR is 0).


2.I enabled vector catch, when SysTick exception is raised PC went to 0x00000000 .


3.Just for curious, I wanted to try what would happen if intvec is copied to ram:


3a. In linker file a intvec area is reserved:

define symbol r_interrupts_start = 0x10000000;
define symbol r_interrupts_end = 0x100000BF;

define symbol m_data_start = 0x100000C0;
define symbol m_data_end = 0x10003FFF - __size_cstack__;

define region RAM_INTVEC_region       = mem:[from r_interrupts_start to r_interrupts_end];



3b. SystemInit is modified:

void SystemInit (void)
    register uint32_t* src = (uint32_t*)0x00000000;
    register uint32_t* dst = (uint32_t*)0x10000000;
    for(uint32_t i = 0; i < 0x30; i++)
        *dst++ = *src++;
    SCB->VTOR = 0x10000000;
    SystemCoreClock = DEFAULT_SYSTEM_CLOCK;


3c. To my suprise, the copied value is the bottom of bootROM ! But the intvec in 0x00000000 is correct :


4.It seems like something went wrong when the debugger is attached, according to the manual boot block is also visible at 0x00000000, maybe the mcu believed the last 512 byte of bootROM is intvec and hardfault happened when an exception is raised, since it can't find the handler address hardfault is raised and PC went to 0x00000000 ?