preform serial dfu for application running with s132

[ziv123]

hello Nordic

i am using nrf52832 soc, sdk 16.0, s132 v7.01

my app requires the s132 

i am trying to understand the bootloader issue, not  so successful on that unfortunately.

 i am using the pca_10040_uart example / pca_10040_uart_debug (which uses different flash space but i believe both should work) 

my scenario: 

1. erase the chip 

2. flash s132 hex

3. flash bootloader form the uart example (Q0: when must i prepare a bl_setting file and merge it or flash it before or with the bootloader ?? )

4. use the nrfutil dfu serial .. on a zip file of my app

Q1: when it works, there are more the 30 seconds that nothing happens, then (if i am on the debug example) i can see the files being moved, is this time normal (it seems to create a problem when i use wtd in my app and do another dfu after app has run) ??

could it be related to the "wait for event" mechanism ? which operates without the sd though there is a softdevice on the flash (see following code)??

static void wait_for_event(void)
{
#if defined(BLE_STACK_SUPPORT_REQD) || defined(ANT_STACK_SUPPORT_REQD)
    (void)sd_app_evt_wait();
#else
    // Wait for an event.
    in_forever_loop++;
    __WFE();
    // Clear the internal event register.
    __SEV();
    __WFE();
#endif
}

Q2: if i want to have an app that uses ble, should i use the dfu over ble example and reconfigure it to use uart for dfu ?? .. if so, how can this be done ?? and if i do use the BLE dfu as bootloader base will i have problems with initiation of sd in the application init ??

Q3: i have tried to compare to uart and ble dfu examples to find out where there is a choice between initiating a uart or ble event handler, and i could not find it .. i saw that this define: "NRF_DFU_TRANSPORT_BLE" make some difference in fstorage which i am not sure i got what it does and what is the difference between sd to nvcm and if that can create some issues with flash placements and bootloader or sd overwritten by app or some mess like that ( cause the mentioned defined also defines the flash area to be protected which is neglected in the uart example

    // Size of the flash area to protect.
    uint32_t area_size;

    area_size = BOOTLOADER_SIZE + NRF_MBR_PARAMS_PAGE_SIZE;
    if (!NRF_BL_DFU_ALLOW_UPDATE_FROM_APP && !NRF_BL_DFU_ENTER_METHOD_BUTTONLESS && !NRF_DFU_TRANSPORT_BLE)
    {
        area_size += BOOTLOADER_SETTINGS_PAGE_SIZE;
    }
    size_of_flash_to_protect = area_size;
    ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR,
                                           area_size,
                                           NRF_BOOTLOADER_READ_PROTECT);

)

also, in the uart sdk_config there is this define : SLIP_ENABLED 1, which i could not find any reference to it in the bootloader project, and in the ble dfu there is this define (which is not in the uart dfu) NRF_SECTION_ITER_ENABLED 1 and again, not sure what what kind of distinction it creates between the uart and the ble dfu

my app flash info is:  FLASH_START=0x26000;FLASH_SIZE=0x3a000 (if this may be required) 

i have read docs about bootloader and bl_setting etc. unfortunately all this theory does not help me to understand what's going on in the bootloader examples

any help would be most appreciated

best regards

Ziv

[Vidar Berg]

Hello,

A1. No, it should not be this slow. Are you using the Segger VCOM or another third party USB-UART bridge to connect to the PC?

A2. The serial bootloader does not care if the main application has BLE or not, so this should be fine.

A3. It should be sufficient to just program the bootloader and Softdevice if you want to test serial DFU. The settings page will be populated by the  bootloader during the DFU update process.

Best regards,

Vidar

[ziv123]

Vidar Berg said:

Are you using the Segger VCOM or another third party USB-UART bridge to connect to the PC?

i am debugging via segger and i am using the nrfutil dfu serial from vscode terminal, though i would not think this two will create such a delay with nothing happening. it seems 

Vidar Berg said:

The serial bootloader does not care if the main application has BLE or not, so this should be fine.

there are a lot of posts about memory layout explaining the difference when having an sd on and without with regard to bootloader, mbr, app start address, not overwriting thigs etc. even in the wait for event, there is a difference if device has sd or not, so are you sure there should be no problem using the uart example as is for application that uses both uart and sd (and wtd, which was an issue as well for some unknown reason) 

Vidar Berg said:

It should be sufficient to just program the bootloader and Softdevice if you want to test serial DFU. The settings page will be populated by the  bootloader during the DFU update process.

so preparing a settings hex is just when i want to have one file of bootloader with sd with app with settings file in one hex, to ease production ?  

[Vidar Berg]

ziv123 said:

i am debugging via segger and i am using the nrfutil dfu serial from vscode terminal, though i would not think this two will create such a delay with nothing happening. it seems 

 So you are connecting via the Segger j-link chip on a Nordic development board? In that case, please try to disable the mass storage class as described here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/tools/nordic_segger.html?highlight=msddisable#disabling-the-mass-storage-device-functionality

ziv123 said:

there are a lot of posts about memory layout explaining the difference when having an sd on and without with regard to bootloader, mbr, app start address, not overwriting thigs etc.

Yes, it obviously affects the memory layout. This is why the bootloader checks if the Softdevice is present to determine where the application image should be placed.

ziv123 said:

even in the wait for event, there is a difference if device has sd or no

 The difference here is if the bootloader utilizes the Softdevice or not (i.e. if it has the BLE DFU transport enabled, or just the serial uart transport).

ziv123 said:

and wtd, which was an issue as well for some unknown reason)

 WDT is a different story. It's not reset through a soft reset like the other peripherals, and therefore the bootloader has to keep feeding it if it was enabled by the application prior to entering dfu mode.

ziv123 said:

so preparing a settings hex is just when i want to have one file of bootloader with sd with app with settings file in one hex, to ease production ?  

 Yes, correct. Manual generation of the settings page is mainly needed when you want to prepare a complete FW image for production.

[ziv123]

Vidar Berg said:

So you are connecting via the Segger j-link chip on a Nordic development board? In that case, please try to disable the mass storage class as described here:

actually i found this post which discuss this issue in regard to nrfutil port recognition 

https://devzone.nordicsemi.com/f/nordic-q-a/55803/nrfutil-takes-34-seconds-before-starting-dfu/237146#237146

nrfutil dfu serial --help
Usage: nrfutil dfu serial [OPTIONS]

  Perform a Device Firmware Update on a device with a bootloader that
  supports UART serial DFU.

Options:
  -pkg, --package FILE            Filename of the DFU package.  [required]
  -p, --port TEXT                 Serial port address to which the device is
                                  connected. (e.g. COM1 in windows systems,
                                  /dev/ttyACM0 in linux/mac)

  -cd, --connect-delay INTEGER    Delay in seconds before each connection to
                                  the target device during DFU. Default is 3.

  -fc, --flow-control BOOLEAN     To enable flow control set this flag to 1
  -prn, --packet-receipt-notification INTEGER
                                  Set the packet receipt notification value
  -b, --baud-rate INTEGER         Set the baud rate
  -snr, --serial-number TEXT      Serial number of the device. Ignored if
                                  --port is set.

  -t, --timeout INTEGER           Set the timeout in seconds for board to
                                  respond (default: 30 seconds)

i set ' -t 1' in the command and puff, 30 sec delay is over, even in debug mode with Segger. so i think this is an elegant solution to the delay, please correct me if i haven't taken under consideration any side affects that might be

Vidar Berg said:

WDT is a different story. It's not reset through a soft reset like the other peripherals, and therefore the bootloader has to keep feeding it if it was enabled by the application prior to entering dfu mode.

this was actually discussed long long in another post i opened but was not solved yet 

https://devzone.nordicsemi.com/f/nordic-q-a/75522/few-questions-about-bootloader-settings/314775#314775

what i see is that when i dfu an app that has no wtd i have no problem when going to dfu from app and restarting the bootloader, but when wtd is active in the app and i set the GPREGRET register and reset, then i don't see feeds in the wtd and after a short time (shorter then wtd feed time) the bootloader resets and goes to app without any dfu preforming 

i added counters to follow what's going on in the feed mechanism

volatile uint32_t feed_counter = 0;
volatile uint32_t feed_request = 0;

static void wdt_feed(void)
{
    feed_counter++;
    NRF_LOG_INFO("First Feed");
    if (nrf_wdt_started())
    {
        for (nrf_wdt_rr_register_t i = NRF_WDT_RR0; i < NRF_WDT_RR7; i++)
        {
            if (nrf_wdt_reload_request_is_enabled(i))
            {
                feed_request++;
                nrf_wdt_reload_request_set(i);
            }
        }
    }
}

a new issue i have encountered when moving from my dev board to pcb is described in this post

https://devzone.nordicsemi.com/f/nordic-q-a/78138/pcb-shuts-down-when-bootloader-starts---just-opened-in-a-new-thread-for-some-order

and is related to preforming serial dfu without HWFC with nrfutil (which i understand needs to be configured differently )

any help on either will be most appreciated

best regards

Ziv

[Vidar Berg]

ziv123 said:

so i think this is an elegant solution to the delay, please correct me if i haven't taken under consideration any side affects that might be

 I think it's ok as long as it works.

ziv123 said:

then i don't see feeds in the wtd and after a short time (shorter then wtd feed time) the bootloader resets and goes to app without any dfu preforming 

 Have you patched the bootloader with this clock driver fix mentioned in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/63998/freertos-wdt-sdk17-problem/263131#263131? If not, the bootloader will not start the LF clock, which again will prevent the RTC from triggering the "WD reload" interrupt.