DFU locked in "reset_wait"

Question

I'm using an nRF51822 with Nordic's connectivity code and serial bootloader example. The connectivity code works great when the bootloader isn't programmed. However, when the bootloader is programmed into flash, I can see that the code gets stuck within a "reset_wait" function upon initial boot when debugging and viewing the code disassembly. "reset_wait" is located at an address within the bootloader address space, so this verifies the UICR register for the bootloader address is set correctly (or at least being set so that the SoftDevice jumps to the bootloader rather than the application). 
 I am using Rowley's CrossWorks for ARM and have written BANK_VALID_APP to the bootloader settings manually to verify it can jump into the application, but it always gets hung up in "reset_wait" regardless of if BANK_VALID_APP is set or not. 
 I have added some code at the beginning of the bootloader to spit some values out the serial port to verify that the bootloader has been entered successfully. These values will appear when running the bootloader on its own, but when an application is programmed and the UICR bootloader address register set, I don't see these values. 
 Any clue as to why the bootloader isn't running properly in the above scenarios? 
 SDK v10.0.0
SoftDevice S110 v8.0.0
Rowley CrossWorks ARM v3.6.3

jpreston · Accepted Answer

I solved my own problem by working with some colleagues more familiar with CrossWorks. Rowley's startup code is expecting a preprocessor definition called "STARTUP_FROM_RESET" to be defined somewhere, otherwise the chip will spin in an endless loop. This is listed in Rowley's docs, but I forgot about it in the bootloader project. 
 Now I'm having a hardfault when the bootloader gets called, but I'll ask a separate question when I find out more information.

DFU locked in "reset_wait"

Top Replies