Good morning,
Is it always required to use Segger J-Link in order to flash Bootloader, Softdevice and Application to a new device?
Could you summarize the different possibilities we have to flash any of these parts?
Furthermore, and regarding the nRF52840: is it possible to use the USB port to flash the device?
Best regards.
you need J-Link to flash bootloader. The Softdevice and the application can be flashed OTA
As Toyman mentioned, you need to program the chip with a bootloader first in order to enable FW update over USB,etc. Different options for programming the chips in production are summarized in this guide: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.gs/dita/gs/prod_test_prog.html?cp=1_0_6
Hi Dani,
I was referring to the bootloader settings page. The NRF_DFU_APP_DATA_AREA_SIZE flag is only used by the bootloader.
Best regards,
Vidar
Hi Vidar,
And what about the settings page that is needed to be modified for debugging?
Where is it? Which settings page are you referring to?
Best regards,
Dani
I have already found this: I had to create the bootloader setting.
I'm referring to bootloader settings page that I assume you've created with nrfutil. Nrfutil has an option (as shown in screenshot) to disable boot validation of the app.
Hi Vidar,
I have succeeded in implementing Buttonless DFU into my prototype and it is working with nRF connect by Nordic: I have created the zip file containing my application and I was able to update the application via DFU using this tool.
The problem is that it takes more than one minute with DFU in 'initializing' state --> please look at the first screenshot showing this situation. After this minute, it starts transferring the file, and once the file is completely transferred, my device is reseted and new application starts working. So,
- Why is it taking such a long time initializing?
- Is it related to application size (zip file size is 131KB)?
When DFU procedure is working, what does it mean? Is it refering to BLE transfer or to the new application transfer inside device memory?
Best regards,
Dani.
Hi Dani,
It should only take a few seconds to pre-validate the update and get started on the transfer. Maybe the buttonless implementation is not transferring execution to the bootloader right away and thus delaying the transfer start? Or do you see the same if you start DFU when the device is already in bootloader DFU mode?
Hi Dani,
It should only take a few seconds to pre-validate the update and get started on the transfer. Maybe the buttonless implementation is not transferring execution to the bootloader right away and thus delaying the transfer start? Or do you see the same if you start DFU when the device is already in bootloader DFU mode?
Hi Vidar,
I have implemented DFU in the same way the 'Buttonless_dfu' is implement. My doubt is related to the 'app_shutdown_handler'. Shoult I have to modify it? Now it is in the following way:
static bool app_shutdown_handler(nrf_pwr_mgmt_evt_t event)
{
switch (event)
{
case NRF_PWR_MGMT_EVT_PREPARE_DFU:
NRF_LOG_INFO("Power management wants to reset to DFU mode.");
// YOUR_JOB: Get ready to reset into DFU mode
//
// If you aren't finished with any ongoing tasks, return "false" to
// signal to the system that reset is impossible at this stage.
//
// Here is an example using a variable to delay resetting the device.
//
// if (!m_ready_for_reset)
// {
// return false;
// }
// else
//{
//
// // Device ready to enter
// uint32_t err_code;
// err_code = sd_softdevice_disable();
// APP_ERROR_CHECK(err_code);
// err_code = app_timer_stop_all();
// APP_ERROR_CHECK(err_code);
//}
break;
default:
// YOUR_JOB: Implement any of the other events available from the power management module:
// -NRF_PWR_MGMT_EVT_PREPARE_SYSOFF
// -NRF_PWR_MGMT_EVT_PREPARE_WAKEUP
// -NRF_PWR_MGMT_EVT_PREPARE_RESET
return true;
}
NRF_LOG_INFO("Power management allowed to reset to DFU mode.");
return true;
}
Apart of this, for DFU I have APP_ADV_INTERVAL set to 80 and APP_ADV_DURATION to 200 (same values as in my application).And in my application, advertising is done every 10s. Should this values cause any problem?
Best regards,
Dani.
Some more information: When I'm using nRF Connect desktop application, it seems that Bootloader do not enter until this 1-minute wait: once DFU is started application continues working normally (nRFConnect, says 'Initializing' -DFU) during this 1-minute. After that time, application is updated succesfully.
On the other hand, when I use Android application, it seems the Bootloader enters just after DFU button is pushed (application is not working): but then, application remains in 'Connecting...' for about 1-minute. After that time, application seems to be updated and it starts running again (Reset is carried out).
Try to change the app_shutdown_handler() implementation so it always return true on NRF_PWR_MGMT_EVT_PREPARE_DFU, then try again with nRF connect for desktop and see if it still takes a minute to get into DFU mode.
The same: around 1 minute. In fact, according the code I have specified above, this function was already returning true.
Furthermore: In my application (when connected) a characteristic sends notifications once every 250ms. With nRF connect (Desktop), if this notifications are enabled, DFU initializing time is practically halved. If notifications are not enabled, time for DFU initialization is around 1m
Dani said:In fact, according the code I have specified above, this function was already returning true
When is the m_ready_for_reset flag set?