Arm Cortex / Traveo II: Stop the secondary cores immediately after Reset

After issuing a Reset in winIDEA, the primary core (Cortex-M0+) is stopped at the reset vector, while the secondary core(s) are IDLE (Debug status IDLE will be shown). The secondary core(s) are then started by the application running on the primary core.

Configuring Hardware | CPU Options | Cores | <secondary core> then Debug Entry | Debug entry type, drop-down Catch does not apply. On this device, this option gets overridden by runtime configuration.

Secondary cores' debug registers are accessible while in IDLE state therefore winIDEA can configure breakpoints. 

Possible solution A

To stop the secondary core after it is released from reset by the application running on the primary core this is one debug procedure you can take:

1. Initiate a debug session in the primary instance of winIDEA with Reset/Download/Attach. 

The primary core should be halted before executing the user application. The secondary core should be in an IDLE state and not executing any code.

2. Open the secondary instance of winIDEA and Attach it to the core.

This will initiate a debug session with the secondary core.

3. Set execution breakpoints in the secondary instance of winIDEA. 

Set a breakpoint in the reset routine if you want to debug the application from the start.

4. Run the application in primary winIDEA.

This will execute the application running on the primary core and if the valid application this will also release secondary core(s) from reset. Any configured breakpoints should be hit by the secondary core and provide step debugging of the initialization code should be possible.

Possible solution B

In this way, the secondary core(s) will be stopped in the boot ROM, even before reaching the reset routine, and all breakpoints within the initialization code should also be hit.

1. In Hardware | CPU Options | Cores | <secondary core> configure CORERESET exception.

2. Initiate a debug session in the primary instance of winIDEA with Reset/Download/Attach. 

3. (optional) Open the secondary instance of winIDEA and Attach to the core.

User-configured exception catch functionality is configured even when secondary winIDEA is not opened. If, in some other use case, you want to avoid this either disable all exceptions or uncheck Automatically observe this core (see picture in step 1. above).

4. (optional) Set execution breakpoints in the secondary instance of winIDEA.

5. Run the application in primary winIDEA.

This will execute the application running on the primary core and if the valid application this will also release secondary core(s) from reset. Configured Vector/Reset Catch will stop the secondary core immediately while still in Boot ROM.

If you opened and attached a secondary instance of winIDEA then step debugging from this location will be possible. Running the secondary core from this location will continue execution to the user application.

More resources

• Core-specific options - winIDEA Help