This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Turning on debug mode causes SPI to fail

I am trying to debug my nRF Secure Bootloader that was modified to DFU another microcontroller attached to the nRF over SPI. The bootloader works well and I can DFU the other microcontroller when I use the bootloader in "release" mode. 

I have noticed that when I build the bootloader in "debug" mode, all the logs turn on and can be read over the RTT, but my SPI master fails. Everything I read on the bus is zero. No fatal errors or assertions. My makefile doesn't do anything else in "Debug" mode other than turn on logs and turn on "assert". I am not aware of anything else the bootloader does differently in debug mode. The application code stays the same when I switch from "release bootloader" to "debug bootloader", and the SPI bus fails there too! (reads in zeroes only) What could be causing my SPI bus to read zeros? 

SDK 14.0.0

Softdevice S132 5.0.0

  • Hi Andrew, 

    I'm not sure why enabling logging can cause the issue. There could be some timing changed when you enable logging, but it should not cause SPI to stop working. Have you checked the output on the SPI pin with a logic analyzer ? Just to make sure it's not the problem on the other side. 

    Are you using the bootloader as SPI Slave or Master ? 

    Could you modify the original to add some SPI code that reproduce the issue (like can output some dummy SPI signal when in normal mode, but output/input all zero when in debug mode ) ? 

  • I want to use a logic analyzer, but my PCB is really small and the SPI pins are not broken out. 

    The nRF is using the SPI master. 

    I don't understand what you mean by "adding SPI code that reproduces the issue". I can already reproduce the issue 5 times by changing only my bootloader make command. 

    Works (SPI works): 

    make clean; make release; make flash sn=260102227

      text	   data	    bss	    dec	    hex	filename
      25300	    184	   7640	  33124	   8164	bin/kiddo_secure_dfu_ble_s132.elf
    

    Does not work: (SPI reads zeroes): (but it compiles and flashes successfully)

    make clean; make flash sn=260102227

       text	   data	    bss	    dec	    hex	filename
      29956	    736	  13272	  43964	   abbc	bin/kiddo_secure_dfu_ble_s132.elf
    

    These are the parts of my makefile that mention "Debug" or "release"

    DEBUG_DEFINES += -DHARDFAULT_HANDLER_ENABLED
    DEBUG_DEFINES += -DNRF_LOG_ENABLED=1
    DEBUG_DEFINES += -DNRF_LOG_USES_RTT=1
    DEBUG_DEFINES += -DNRF_LOG_BACKEND_RTT_ENABLED=1
    
    RELEASE_DEFINES += -DNDEBUG  # turns off assert
    RELEASE_DEFINES += -DNRF_LOG_ENABLED=0
    RELEASE_DEFINES += -DNRF_LOG_USES_RTT=0
    RELEASE_DEFINES += -DNRF_LOG_BACKEND_RTT_ENABLED=0
    
    debug: DEFINES += $(DEBUG_DEFINES) 
    debug: setup $(BIN) $(HEX)
    
    release: DEFINES += $(RELEASE_DEFINES)
    release: clean setup $(BIN) $(HEX)
    
    flash: debug
    	@echo Flashing: $(HEX)
    	nrfjprog -f nrf52 --sectorerase $(NRFJPOG_SERIAL_NUMBER) --program $(HEX)
    	nrfjprog -f nrf52 --reset $(NRFJPOG_SERIAL_NUMBER)
    
    clean:
    	@echo removing build and bin directories
    	rm -rf $(BUILD_DIR)
    	rm -rf $(OUTPUT_DIR)
    
    

    I even tried changing  NRF_LOG_DEFAULT_LEVEL from 3 to 0 to see if it was just to logs causing the SPI issue, but the SPI still breaks when NRF_LOG_DEFAULT_LEVEL = 0. Now I don't know what to do. 

     

  • What I mean was to test with unmodified bootloader, the one we provide in our sdk. You just add some very simple SPI code in and can reproduce the issue. So that we can test here. 

    I assume that you changed the bootloader start address to fit the bigger size of the bootloader after you enable logging. 

Related