AnsweredAssumed Answered

VTOR unexpectedly set in debug session

Question asked by Luke Studer on Jun 1, 2018
Latest reply on Jun 5, 2018 by Luke Studer

Hi,

 

I have been trying to update the code for my current LPC1788-based project to MCUXpresso v10.2.0 from v10.0.2; however, I am encountering issues preventing me from debugging the firmware.  As I state in the description, the source of the problem during a debug session is that the VTOR register has a non-zero value in it at a time when it should not.  It appears that the value in the register is not being cleared on reset.

 

I'll describe my code setup a bit to try to make things clear.  We are using a custom bootloader for which we generate a separate image that we load at address 0 in internal flash; we reserve the first 0x4000 for it.  Our main application occupies the rest of flash.  The bootloader is the only place in our code where we set the VTOR, which the bootloader does once its work is finished (it sets it to 0x4000).

The bootloader needs to communicate over SSP0 to determine if it needs to do a firmware update.  Our interrupt-driven SPI communication is in a static library that both the bootloader and application reference, so they each have a copy of (among other things) the SSP0 IRQ handler and the associated state variable, XfrMode, that the IRQ handler reads and updates as it runs. 

 

The problem I am having occurs when I attempt to run a debug session on our main application.  Since resetting the processor clears the VTOR, the bootloader runs after the debug probe flashes the main application.  The bootloader is getting stuck waiting on XfrMode, which is never changing (I verified the address I was stuck at was where the bootloader waits on XfrMode to be set to its "done" value).  I found that, at this point in time, the VTOR (address 0xE000ED08 according to the LPC1788 User's Guide) has 0x4000 in it, which is causing the main application's instance of the SSP0 IRQ handler to run (instead of the bootloader's), which will not update the instance of XfrMode that the bootloader uses; hence, why it gets stuck.

 

If I force the VTOR to 0 at the start of the bootloader, it resolves this issue.  However, I am trying to figure out why this behavior occurs now when it did not in the older IDE version.

 

The settings in my debug configuration are the default settings the IDE generated when I first started a debug session.  I tried, among other things, changing the "Reset Handling" parameter from VECTRESET to both SOFT and SYSRESETREQ.  Setting it to SOFT yielded some results: the VTOR value was apparently 0 for most of the bootloader, since the debugger successfully stopped at main() (of the application).  Sadly, the SOFT reset introduced another problem I can not find a workaround for: in the application, the SSP0 interrupt is not being generated despite being enabled (SSP0->IMSC.TXIM and SSP0->RIS.TXRIS are both set; NVIC indicates SSP0 interrupt is priority 0; and PRIMASK register is 0).

I did see that the BASEPRI register (which we never modify in our code) is set to an invalid value (1) when the debugger breaks at main(), and the value does not change when I try to write it with the CMSIS __set_BASEPRI() call (we are running in privileged mode, CONTROL register is 0, so it should work to my knowledge).  I'm guessing this invalid BASEPRI value is keeping the SSP0 interrupt from being serviced.

 

Thanks for reading this far!  I am more interested in why VTOR is the wrong value inside the bootloader, but if anybody has any thoughts on the SOFT reset and BASEPRI stuff, I'm curious about that as well.  Let me know additional info you might need.

 

Thanks for your help,

Luke

Outcomes