my 52832 go to bootloader for about 1minute when it power on, what's wrong and how to tackle. Now i am tracking that referring to the implements of bootloader. normally, when the chip power on, it runs MBR->softdevice ->bootloaer->application. can you supply the related information?
The answer may differ between different versions of the SDK and different nRF5-series devices.
my 52832 go to bootloader for about 1minute when it power on, what's wrong and how to tackle.
With an assumption that you are on SDK 14.0.0 or newer and an nRF52832 device. The 1 minute delay is about what you would expect to see from a bootloader which stays in bootloader mode until nrf_dfu_inactivity_timeout_timer expires after 40 seconds. You need to check if there is some reason nrf_dfu_enter_check is indicating that you should stay in bootloader mode.
As a more general suggestion, I would recommend setting up a toolchain which allows you to get some debugging information out. You can either add logging so that you are able to get information about what the bootloader is doing or run the bootloader with a debugger like the one present in our IDEs or a standalone solution like Segger Ozone. Doing this will allow you to get a clear picture of what the bootloader is actually doing, so debugging gets more manageable.
Now i am tracking that referring to the implements of bootloader. normally, when the chip power on, it runs MBR->softdevice ->bootloaer->application. can you supply the related information?
You are quite close, except the fact that the SoftDevice is never the main firmware the SoftDevice is running. The only times the SoftDevice is running is when the bootloader or application calls a sd_... function or when an interrupt happens.
What happens when the nRF52 is powered on is that the MBR will look at the UICR address 0x10001014 where the address of the firmware should be located. When running just a single application this address will be the address right after the end of the SoftDevice where the app itself is located. When running a bootloader, this address will be the BOOTLOADER_START_ADDR as shown below. In your setup, when the MBR is done with its startup tasks it will jump to the bootloader. The bootloader will check the conditions in its settings, the state of bank 0 where a valid app may be present, the state of the bootloader button if you have one, and other custom conditions in nrf_dfu_enter_check. If the conditions tell it to do so, the bootloader will uninitialize its hardware and jump to the application.
volatile uint32_t m_uicr_bootloader_start_address __attribute__ ((section(".uicr_bootloader_start_address"))) = BOOTLOADER_START_ADDR;
Best regards,
Rune Holmgren
The answer may differ between different versions of the SDK and different nRF5-series devices.
my 52832 go to bootloader for about 1minute when it power on, what's wrong and how to tackle.
With an assumption that you are on SDK 14.0.0 or newer and an nRF52832 device. The 1 minute delay is about what you would expect to see from a bootloader which stays in bootloader mode until nrf_dfu_inactivity_timeout_timer expires after 40 seconds. You need to check if there is some reason nrf_dfu_enter_check is indicating that you should stay in bootloader mode.
As a more general suggestion, I would recommend setting up a toolchain which allows you to get some debugging information out. You can either add logging so that you are able to get information about what the bootloader is doing or run the bootloader with a debugger like the one present in our IDEs or a standalone solution like Segger Ozone. Doing this will allow you to get a clear picture of what the bootloader is actually doing, so debugging gets more manageable.
Now i am tracking that referring to the implements of bootloader. normally, when the chip power on, it runs MBR->softdevice ->bootloaer->application. can you supply the related information?
You are quite close, except the fact that the SoftDevice is never the main firmware the SoftDevice is running. The only times the SoftDevice is running is when the bootloader or application calls a sd_... function or when an interrupt happens.
What happens when the nRF52 is powered on is that the MBR will look at the UICR address 0x10001014 where the address of the firmware should be located. When running just a single application this address will be the address right after the end of the SoftDevice where the app itself is located. When running a bootloader, this address will be the BOOTLOADER_START_ADDR as shown below. In your setup, when the MBR is done with its startup tasks it will jump to the bootloader. The bootloader will check the conditions in its settings, the state of bank 0 where a valid app may be present, the state of the bootloader button if you have one, and other custom conditions in nrf_dfu_enter_check. If the conditions tell it to do so, the bootloader will uninitialize its hardware and jump to the application.
volatile uint32_t m_uicr_bootloader_start_address __attribute__ ((section(".uicr_bootloader_start_address"))) = BOOTLOADER_START_ADDR;
Best regards,
Rune Holmgren