I'm implementing a system based on the STM32L0 line of microcontrollers that uses an external interrupt to trigger an SPI read from an external sensor (a DW1000 UWB module). I am not running any sort of OS. The microcontroller runs through all of the initialization code, but just before I enter the infinite while, I want to enable interrupts, so I call the __enable_irq() intrinsic found in CMSIS_gcc.h. When the microcontroller enters into the function, it does not return, and the debugger outputs the following repeatedly:

Performing single step... ...Target halted (DBGRQ, PC = 0x0800460C) Reading all registers

The disassembly looks like this:

 __ASM volatile ("cpsie i" : : : "memory");
0800460a:   cpsie   i
0800460c:   b.n     0x800460c <main+144>
0800460e:   bl      0x80043f4 <Error_Handler>
08004612:   nop     ; (mov r8, r8)
08004614:   ldr     r0, [r0, r0]
08004616:   ands    r1, r0
08004618:   asrs    r0, r0, #32
0800461a:   ands    r2, r0
0800461c:   b.n     0x8004640 <RTC_IRQHandler+4>
0800461e:   b.n     0x8004622 <main+166>
08004620:   ldrb    r7, [r7, #31]
08004622:           ; <UNDEFINED> instruction: 0xffff0764
08004626:   movs    r0, #0

I'm thinking the line at address 0x800460c is suspicious because it shouldn't be attempting to branch to itself, but I am having a hard time understanding the programming manual and the .n suffix of the b instruction. The C-code follows:

  /* Ensures IRQs are only enabled once. */
  prim = __get_PRIMASK();
  if(!(prim & 0x01)){


__attribute__( ( always_inline ) ) __STATIC_INLINE void __enable_irq(void)
  __ASM volatile ("cpsie i" : : : "memory");

Any direction is helpful. Thank you!

  • 1
    \$\begingroup\$ I haven't analysed the assembly code so this may be incorrect. But, I suspect your code is entering an ISR but that routine isn't clearing the interrupt flag. So, the ISR finishes and is immediately triggered again... and again... \$\endgroup\$ – bitsmack Jul 12 at 23:52
  • \$\begingroup\$ From the ARM Documentation: In Thumb code the .N width specifier forces the assembler to generate a 16-bit encoding.. So that's part isn't particularly suspicious. \$\endgroup\$ – brhans Jul 13 at 0:36
  • \$\begingroup\$ I agree with @bitsmack here, yet I think an interrupt occurs (or has already occured) which wasn't setup properly (i.e. no interrupt handler defined). \$\endgroup\$ – Tom L. Jul 13 at 6:31

I was performing all of my computations (full TDoA multilateration algorithm) inside the ISR, which was most likely overflowing the stack. I moved the algorithm outside the ISR and instead saved the data in a FIFO to process later. This solved the issue. Thank you all for the suggestions, they were very helpful in investigating the interrupt!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.