Difference between revisions of "Delayed Program Start in Debug"
(→Instrument the Startup Code) |
(→SETUP) |
||
Line 32: | Line 32: | ||
The project can be easily ported to any other Cortex-M based MCU.<br> |
The project can be easily ported to any other Cortex-M based MCU.<br> |
||
===SETUP=== |
===SETUP=== |
||
− | *J-Link software: V7. |
+ | *J-Link software: V7.58 (or later) |
− | *Embedded Studio: V5. |
+ | *Embedded Studio: V5.62 (or later) |
*Hardware: SEGGER Cortex-M Trace Reference Board (ST STM32F407VE device) |
*Hardware: SEGGER Cortex-M Trace Reference Board (ST STM32F407VE device) |
||
− | *Project: [[File:SEGGER_Cortex- |
+ | *Project: [[File:SEGGER_Cortex-M_Trace_Reference_Board_Blinky__DelayedProgramStart_ES_V562.zip]] |
===Test & Verify functionality using J-Link Commander=== |
===Test & Verify functionality using J-Link Commander=== |
Revision as of 18:05, 6 December 2021
Contents
In debug mode, users expect the MCU to be halted right before executing the target application. Usually, the J-Link archives this by configuring debug logic of the MCU accordingly. Of course, this assumes that a debug reset does not reset the debug logic. This applies for most MCUs but unfortunately not for all. For MCUs where the debug logic does not survive the reset, the J-Link has no chance to force the MCU to automatically halt after reset.
Problem
After reset, the MCU automatically jumps to the user application and starts executing. The J-Link tries to re-enable the debug logic + halt the MCU as soon as possible but there is no guarantee that this can be done fast enough. In case of the application has been already started, any further action may result in unexpected behavior.
Solution
Add a delay loop (e.g. 1 second) in the beginning of the startup code. The idea is to give the J-Link a defined timeframe to re-enable the debug logic + perform the halt request before the actual application code is executed. We recommend to enable this delay loop in the debug configuration of your project, only.
Instrument the Startup Code - Cortex-M
The following instructions needs to be added to the startup code. Please note that the number of the delay loops needs to be adjusted depending on the CPU frequency. In this example, a STM32F4 has been used which runs at 16 MHz after reset.
//
// Execute a ~1 second delay loop
//
#IF DEBUG
mov r0, 0x300000
Delay_Loop:
subs r0, #1
cmp r0, #0
bne Delay_Loop
#endif
Instrument the Startup Code - Cortex-A/R
TBD
Instrument the Startup Code - RISC-V
TBD
Example
The following example project was created with the SEGGER Embedded Studio and runs out-of-the-box on SEGGERs Cortex-M Trace Reference Board. It is a simple blinky application which toggles LED0. It makes use of a generic startup code which has been instrumented as described above.
The project can be easily ported to any other Cortex-M based MCU.
SETUP
- J-Link software: V7.58 (or later)
- Embedded Studio: V5.62 (or later)
- Hardware: SEGGER Cortex-M Trace Reference Board (ST STM32F407VE device)
- Project: File:SEGGER Cortex-M Trace Reference Board Blinky DelayedProgramStart ES V562.zip
Test & Verify functionality using J-Link Commander
- Download the application using Embedded Studio to the target
- Connect to the target using J-Link Commander
- Perform a reset
- Check PC (== 0x0800010E)
- Switch reset strategy to Reset + Halt After Bootloader
- Perform a reset
- Check PC (== 0x08000116)
Conclusion / Summary
After performing the normal reset, the MCU is halted on the reset vector (Reset_Handler / 0x0800010E).
After performing a reset via reset + halt after bootloader strategy, the MCU is halted on the instrumented startup code (0x08000116)
This confirms that the reset behaves as expected.
In order to simulate a bootloader, the instrumented code may be moved from the startup code to somewhere in the user application. Performing a reset should show that the CPU is halted at the address where the instrumented code has been moved to.