I am using the LPCXpresso IDE
I have a program and a bootloader. I can successfully run and debug, jumping from the bootloader into my application code. The one thing I can no longer do, since adding the bootloader, is use the reset button during debugging. This means if I want to restart, I have to exit the debugger and restart the debugger, including flashing the application, which is kind of a pain.
I am guessing that the problem is related to moving the VectorTable. The VT starts at zero for the bootloader, then right before calling my code, I update it to 0x4000 (the base of my app). I'm guessing that when I press the reset button, not having the VTOR register pointing to the VT at 0x0000 is causing a problem. How can I resolve this?
Just for reference, here is the code from my bootloader that launches the application:
unsigned int stack_adr = code_base_adr;
stack_adr = *(unsigned int*) stack_adr;
__set_MSP(stack_adr);
SCB->VTOR = code_base_adr;
user_entry = (USER_ENTRY_PFN)*((uint32_t*)(code_base_adr +4));
(user_entry)();
I don't know the answer but just my point of view to this. I never ever tried to debug application when loaded through my custom bootloader. And never thought it could be possible.
We're using different approach. To debug application code with LPCXpresso debugger, we've made different build configuration (with default linker command file) where the application normally compiles and runs without the need of a bootloader.
For debugging the application when loaded through bootloader we use ONEinspect, a real time debugger. We use its downloader feature as well.
Robert,
may be I wasn't much clear, my suggestion is try to debug with a couple of breakpoint in the 2 address related to the reset vector(s) and click the Restart button in LpcXpresso. It is the button similar to Run with a yellow back arrow on it.
Hi Robert
> The one thing I can no longer do, since adding the bootloader, is use the reset button during debugging
I have verified that, at some level on some boards, pressing reset does not disrupt the debugger's connection to the debug port on the board. In principle, at this level, it should be possible to continue a debug session.
I have also found that some operations (e.g. single step) after <halt the processor> <reset the processor> trigger a fault in some of the versions of arm GDB that we supply with LPCXpresso (e.g. in LPCXpresso 8.2 I receive the message "Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)")
I would be quite interested to know exactly what your situation is and what actually happens after you use reset.
- could you let us see the 'Debug messages' (one of the consoles you can select in the console view )?
- and the arm-eabi-none-gdb console too
- and (if you are finding that the debug connection is dropped) the RedlinkServer console
The debug messages will be more useful (although much larger) if you set Preferences > LPCXpresso/Debug Options (advanced) : Extended Debug Trace (DEBUG_TRACE) to a value with lots of bits set such as 0xFFFFFF.
Presumably you are doing something like <halt the processor> <reset the processor> <something else>. It would be useful to know which <something else> corresponds to any traces you supply.
> I have to exit the debugger and restart the debugger, including flashing the application, which is kind of a pain.
Don't forget that you can continue debugging an existing run - without re-flashing - by using the 'Attach only' feature. You turn this by right-clicking on your project with Launch Configuration > Edit Current... : Debugger Tab : 'Target Configuration' then edit the line in the table named 'Attach only' to True. (Don't forget to set it back to False when you need to reboot again.)
Any update on this issue?
Sorry, I currently can't see any simple way of being able to use the Restart button within the IDE for debugging through a bootloader like this.
You could maybe try setting the PC and SP register contents manually back to the corresponding values in the vector table of your main application image?
Regards,
LPCXpresso Support
Can you explain why it won't work? What does the reset button do, does it trigger a HW reset? Does triggering a HW reset (e.g. if I put an external reset hw reset button) cause the debugger to disconnect? Is that what's happening, is that why it's not working?
Pressing the LPCXpresso reset button the first time, does appear to reset the application correctly, it's just that after that, the debugger doesn't seem to work correctly and I can't use the reset button a second time. Is that because the reset caused the debugger to disconnect? How do you know the debugger disconnected?
Here is the information collected and some background
I'm using LPCXpresso 7.9.2 - I can't upgrade at the moment because I am working to get a product into certification and cannot afford to change any tool configurations.
Bootloader is at 0x0000
Application is at 0x4000
Application ResetISR is at 0x4156
I put a breakpoint at the App ResetISR
Here is the information you requested:
LPCXpresso RedlinkMulti Driver v7.9 (Aug 11 2015 15:51:11 - crt_emu_cm_redlink build 486)
Found chip XML file in /Volumes/Ingenutec/Active Project Code/IPS/workspace/Meter/Release/LPC1756.xml
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.112 (NXP Semiconductors)
VID:PID: 1FC9:0090
USB Path: USB_1fc9_0090_26200000_ff00
Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
loaded v.2 On-chip Flash Memory /Applications/lpcxpresso_7.9.2_493/lpcxpresso/bin/Flash/LPC175x_6x_256.cfx
image 'LPC175x_6x (256K) Aug 11 2015 16:53:23'
Connected: was_reset=false. was_stopped=false
LPCXpressoPro Full License - Unlimited
Writing 194624 bytes to address 0x00004000 in Flash
Progress meter completed at over 100% (196608/194624 bytes)
Erased/Wrote page 4-20 with 194624 bytes in 2661msec
Flash Write Done
Writing 8 bytes to address 0x0003FFF8 in Flash
Erased/Wrote page 21-21 with 8 bytes in 840msec
Flash Write Done
Flash Program Summary: 194631 bytes in 3.50 seconds (54.29 KB/sec)
Stopped (Was Reset) [Reset from Unknown]
Stopped: Breakpoint #1
Stopped: Step (Halt)
Stopped: Halt
Stopped: Breakpoint #1
Stopped: Breakpoint #1
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
0x00023926 in SBL_RxReady () at ../sbl_drivers/lpc17xx/source/lpc17xx_sbl_i2c.c:73
73 if((I2C_DEV->I2CONSET & I2C_I2CONSET_SI) == 0)
Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint 1, ResetISR () at ../src/cr_startup_lpc176x.c:276
276 ResetISR(void) {
Program received signal SIGINT, Interrupt.
0x00023aee in SBL_SlaveCmdRecv (pError=0x2007d83b <xHeap+6203>) at ../sbl/sbl_slave.c:103
103 *pError = FALSE;
Cannot access memory at address 0xa5a5a5a5
Quit
Breakpoint 1, ResetISR () at ../src/cr_startup_lpc176x.c:276
276 ResetISR(void) {
Breakpoint 1, ResetISR () at ../src/cr_startup_lpc176x.c:276
276 ResetISR(void) {
[Started server]
[Connected on port 3025]
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.112
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_26200000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.112
VID = 1FC9, PID = 0090
Path = USB_1fc9_0090_26200000_ff00
IsOpen = FALSE
WireInitialized = FALSE
WireProtocol = JTAG
CoresConfigured = FALSE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
FALSE
redlink>ProbeOpenByIndex 1
Probe Handle 1 Open
redlink>WireIsConnected 1
FALSE
redlink>WireSwdConnect 1
DpID = 2BA01477
redlink>CoresConfigured 1
FALSE
redlink>CoreConfig 1
Number of CORES/TAPs = 1, Fully recognized: True
[Closed]
[Started server]
[Connected on port 3025]
redlink>ProbeStatus
redlink>exit
[Closed]
[Started server]
[Connected on port 3025]
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.112
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_26200000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.112
VID = 1FC9, PID = 0090
Path = USB_1fc9_0090_26200000_ff00
IsOpen = FALSE
WireInitialized = FALSE
WireProtocol = JTAG
CoresConfigured = FALSE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
FALSE
redlink>ProbeOpenByIndex 1
Probe Handle 1 Open
redlink>WireIsConnected 1
FALSE
redlink>WireSwdConnect 1
DpID = 2BA01477
redlink>CoresConfigured 1
FALSE
redlink>CoreConfig 1
Number of CORES/TAPs = 1, Fully recognized: True
I will collect the traces you request. When you say "on some boards, pressing reset...", you do mean the reset button in LPCXpresso, not the reset on the board, correct? Specifically, I am referring to the reset (or restart) button in LPCXpresso.
> Don't forget that you can continue debugging an existing run - without re-flashing - by using the 'Attach only' feature.
Yes, and I use this often for other purposes, but not when I'm wanting to restart the app. This approach doesn't help if, for example, I'm stuck in an infinite loop, or have hit a hardware exception, I just get re-attached to an app that is still stuck. Generally, if I'm wanting to press the restart button, it's because I want my app to restart, just as if I had finished loading it and done a hardware reset.
Hi Robert,
you may check if you are right adding a couple of breakpoints on the Reset address or in the Reset Handler. I may suppose that the LpcXpresso reset button could be linked to the JTAG/SWD reset management.
If I remember well SWD has direct access to the AIRCR that inside has 2 bits related to reset the microcontroller. I may suppose the reset button linked to SWD and asking a local reset of the mcu so it should be simple to verify and debug.
N.B. There is no so much documentation about AIRCR register.