NVIC_SystemReset() vs Sys_BootROM_Reset()

I’ve implemented a command line interface using RTT over and in the interface I have the ability to force a reset using either NVIC_SystemReset() or Sys_BootROM_Reset(). I have a couple interesting differences between the two and I’m wondering if there is any explanation for these.

I am running my code on the RSL10 EVB, using a Segger J-Link Plus Compact, and early in main() I read/save the digital and analog reset reasons and clear them both.

  • NVIC_SystemReset()

    1. System seems to reset but then hangs; I need to disconnect the RTT Viewer and then reconnect, at which time my typical boot logging shows up on the viewer.
    2. The reset reason is: digital - ACS_RESET_SET, analog - CLK_DET_RESET_FLAG_SET
    3. If in a debug session, this reset causes gdbserver problems as it can’t seem to halt the CPU and all registers are DEADBEEF. I can regain control if I again disconnect and reconnect the RTT Viewer.
  • Sys_BootROM_Reset()

    1. System resets and I see my typical boot logging showing up immediately in the RTT Viewer.
    2. The reset reason shows no flags set (i.e., none in digital and none in analog)
    3. If in a debug session, this reset acts as expected, reset and halted at main().

How are these two reset call different and is there any explanation for the code “hanging” until the RTT Viewer is disconnected and reconnected?


A. Sys_BootROM_Reset() uses the watchdog timer structures to reset the device. While in debug, the watchdog is disabled and will not trigger a reset.
It will do boot_rom_reset, it will clear all flags. So there are not any reset flags.

B. NVIC_SystemReset() performs a reset of the Arm Cortex-M3 processor and it’s surrounding digital subsystem, but not the analog components (and possibly not the LPDSP32).
It clears all digital subsystem, so you still can see ACS information. (like digital - ACS_RESET_SET, analog - CLK_DET_RESET_FLAG_SET).

@martin.bela thanks, that helps explain some things. One clarification - you said NVIC_SystemReset() will clear surrounding digital subsystem. Does that mean the ARM core and its “private peripherals”, or does that mean those peripherals as well as all the External Digital Interfaces and Peripherals (i.e., CRC, DMA, etc)?

Is there any explanation for why the system would hang until I Connect the RTT Viewer? I have RTT configured as “NO_BLOCK_TRIM”. I have also tried these experiments with a release build and and also with the JLink probe physically disconnected after using JFLash to program it. In all cases it seems that my code is “stuck” until RTT Viewer is connected (this is even the case when I build the firmware with OUTPUT_INTERFACE=DISABLED).

Is there some way that the ARM debugger interface is stuck and on boot and breakpoints/halts the CPU? I don’t believe I used to have the problem, so I am wondering if somehow I introduced it in my code.

Hi @mbianchi
A1: Yes.Your understading is correct. NVIC_SystemReset() will reset all ARM digital subsystem. All the digital registers will be reset which is included Debug Port.
Only analog component has no change. (like ACS_** registers, see Hardware reference A.21)

A2. I guess you reconnect RTT viewer will have RESET signal to the chip.
NVIC_SystemReset() will reset all digital interface. All the pre-configuration is released.

Thanks @larry.zhu for the clarification. So I have found the root cause of my issue but I don’t know the internal explanation.

What I thought was my code hanging was not actually the case. It turns out parts of it were running about 45x slow. I am using FreeRTOS and what I discovered after a huge amount of experimenting, GPIO instrumentation, etc. is that the SysTick clock is getting slowed down due to a WFI instruction in the Idle Task. I just changed the SysTick timer to use the SLOWCLK/32 source and everything is working fine, in all cases. I’m sure I never noticed the “IMPORTANT block” in section 14.2 SysTick, which mentioned this unexpected behavior of the SYSCLK slowing down due to a WFI instruction. Wow, this was a major time sink to track this problem down.

What I don’t understand (and at this point the answer would just be academic) is why connecting to RTT seems to keep this SYSCLK slowdown from happening. There must be something going on deep inside the RSL10 which is causing this weird behavior.