Unable to create bootloader for nRF52832

[buchnich]

Hello,

I am creating a wearable PCB with the Raytac MDBT4Q-P BLE module, which uses the nRF52832. I need this device to have OTA firmware capability, but I'm finding it nearly impossible to create a simple bootloader. I'm following this guide for creating the bootloader. Unfortunately, I've been having all sorts of issues trying to set this up on Mac, Windows, or Linux operating systems. Before I do a deep dive into troubleshooting my issues, I need to ask; is there just a standard bootloader .hex file that I can download somewhere and flash to the board? The process for creating a simple bootloader is extremely convoluted and requires that multiple 3rd-party tools work perfectly.

Thank you,

Nick 

[bjorn-spockeli]

Hi Nicholas, 

we have pre-compiled binaries for many of our examples in the nRF5 SDK. 

You can find the pre-compiled debug version of the bootloader for the nRF52832 DK( PCA10040) in <SDK folder> \examples\dfu\secure_bootloader\pca10040_s132_ble_debug\hex. Note this is compiled for the PCA10040 board, but it should work on custom boards as well, but the LED and button pins might not be correct. However, you should be able to see the Raytac module advertise as DfuTarg if it works. 

I recommend using the latest SDK, i.e. SDK v16.0.0. 

Best regards

Bjørn

[buchnich]

Bjorn,

I wasn't using the _debug folder, which is why I couldn't find the hex file. I have a custom board, so I will test it out later to see if everything still works. I'll verify your response as the answer if that goes well.

Thanks!

Nick

[bjorn-spockeli]

No, the bootloader will write its start address to the MBR on boot and then following code line 

#define BOOTLOADER_ADDRESS      ((*(uint32_t *)MBR_BOOTLOADER_ADDR) == 0xFFFFFFFF ? *MBR_UICR_BOOTLOADER_ADDR : *(uint32_t *)MBR_BOOTLOADER_ADDR) /**< The currently configured start address of the bootloader. If 0xFFFFFFFF, no bootloader start address is configured. */

will retrieve the bootloader address by de-referencing the pointer to the memory address where the bootloader address is stored. 

Best regards

Bjørn

[bjorn-spockeli]

So you flash the precompiled bootloader hex and then you're not able to flash the buttonless DFU application from our SDK? Are you using Segger Embedded Studio?

[buchnich]

Yes. I am using SES. SES says that the download is successful, but I don't see anything on the RTT logger. However, when I use J-Flash Lite to first erase the board before flashing the buttonless DFU example, then I see output on the logger.

[bjorn-spockeli]

I have had some issues with getting the RTT log to show up in SES when running a debug session. I am not quite sure what the cause for this is, but I have registered a support ticket with Segger on this. 

Are you using the Jlink RTT viewer when flashing the buttonless DFU example with J-Flash Lite? So you do not see any log output from the bootloader when flashing the precompiled bootloader hex?

It could be that the bootloader is compiled with UART as the logger backend and not RTT. 

[buchnich]

I used J-Flash Lite to flash the bootloader to the board. I then used SES to flash the Buttonless DFU example directly from SES. When I did this after flashing the bootloader, I didn't see anything when connected to RTT viewer. However, if I erased the board using J-Flash Lite, then again flashing the buttonless DFU example with SES, I was able to see the error output on the RTT viewer application. The error was something like "bootloader not found...fatal error". This makes sense since the device was erased.

I'm sure that the RTT logger backend was enabled. The UART was disabled in the sdk_config.h file.

[bjorn-spockeli]

buchnich said:

I'm sure that the RTT logger backend was enabled. The UART was disabled in the sdk_config.h file.

 In both the bootloader and the application?  

I forgot to mention that RTT places a control block in RAM and when RTT is enabled in both the application and bootloader, then SES does not know which block that belongs to which part of the code. It will genrally just search for the SEGGER RTT string in ram and use the first block it finds. You can place the RTT control block in the same location in RAM to avoid this, see https://devzone.nordicsemi.com/f/nordic-q-a/30310/easy-way-to-merge-bootloader-and-application-rtt-output.

[buchnich]

Ah, this is good to know. I will hopefully be able to test this later tonight. I would've never realized that without seeing that post. Thank you.