nrf_dfu_transports_init() error in background dfu

[alex kim]

Hi,

I am using 

• PCA10056
• SDK 15.3.0
• Keil IDE
• The soft device is S140 
• JLinkRTTViewer for debug

I am testing background serial-dfu.(refer to https://devzone.nordicsemi.com/f/nordic-q-a/46336/bootloader-no-transport-dual-bank-dfu-and-dependencies)

I erase 52840 whole and write SoftDevice & bootloader.

I used keil debug to download the app and run.

An error occurred with the attachment.

Please advise

Alex

[Vidar Berg]

Hi Alex,

Looks like the error comes from the uart_dfu_transport_init() function in nrf_dfu_serial_uart.c. Please try to debug this function to find out what's returning the error. 

Best regards,

Vidar

[alex kim]

Hi Vidar,

1 ) It returns 0x08 from nrf_dfu_transport_init (dfu_observer).

      An error occurred with the attachment.

2) I set NRF_LOG_ENABLE to 1 in the bootloader and the application.

     The bootloader prints messages well, but the application does not print them.

     Please advise.

[Vidar Berg]

Hi,

1. Yes, the driver will return the invalid state error if you try to init the same UART twice. 

2.  Notice it says "cache_too_small: false". So it is enough cache to store the new image.  However, "cache_address" is wrong. It should start at bank 1, not bank 0 where the current application resides.

[alex kim]

Hi,

I am continuing the background dfu test.

1. Why did the following message appear when I turn the power on?

   app: Incorrect bootloader start address. Set BOOTLOADER_START_ADDR to 0xE4000

2. Is the log progress correct?

   I don't know why it doesn't progress at all after the last message in the log.

  00> <debug> app: Bank 0 code: 0x01: Size: 0x296F0
  00>
  00> <debug> app: Bank 1 code: 0x00: Size: 0x0
  00>
  00> <debug> app: pass: 0.
  00>
  00> <debug> app: cache_address: 0x50000.
  00>
  00> <debug> app: cache_too_small: false.

Please advise.

[alex kim]

Hi,

Downloading using the bootloader on the target board works well and runs normally.

Using background dfu causes the same problem as above.

[Vidar Berg]

Hi,

1. What is BOOTLOADER_START_ADDR set to in your project settings? The problem is that it doesn't correspond to the actual bootloader start address.

2. This one looks better. Bank 0 looks to contain valid data and the cache is starting at bank 1.

[alex kim]

Hi Vidar,

Sorry for asking too basic questions often.

1. Where and how do I set BOOTLOADER_START_ADDR in Keil?

 <info> app: bootloader_addr_actual = E4000 bootloader_addr_expected = 26000
 00>
 00> START_ADDR to 0xE4000

 In secure_bootloader(uart), IROM1 is set to 0xE4000.

2. I get the following error message.

00> <debug> app: cache_address: 0x50000.
00>
00> <debug> app: cache_too_small: false.
00>
00> <debug> app: keep_firmware: true.
00>
00> <debug> nrf_dfu_settings: Writing settings...
00>
00> <debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
00>
00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 0
00>
00> <error> app: SOFTDEVICE: INVALID MEMORY ACCESS

Best regards,

Alex

[Vidar Berg]

Hi Alex,

1. You can define the BOOTLOADER_START_ADDR symbol in options for target --> C/C++ --> Preprocessor symbols. E.g., BOOTLOADER_START_ADDR=0xE4000 if 0xe4000 is the start address of your bootloader

2. You need to use the "nrf_fstorage_sd" when the Softdevice is enabled because the nrf_fstorage_nvmc will access the NVMC registers directly. This is why you get the invalid memory access assertion.

[alex kim]

Hi Vidar,

Thank you for your kind reply every time.
I'm using secure_bootloader \ pca10056_uart_debug.
a nrf_fstorage_nvme.c is used for secure_bootloader.
a nrf_fstorage_sd.c is used for background dfu by using ble.
I'm not sure if "SOFTDEVICE: INVALID MEMORY ACCESS" is occurring.

[Vidar Berg]

Hi Alex,

The screenshot in your previous response shows that p_fs->p_api was set to "nrf_fstorage_nvmc" when you got the assertion. Please double-check this.

[alex kim]

Hi Vidar,

Please double-check this.

No Links Linked to This.

[Vidar Berg]

Hi Alex,

Are you still getting the Softdevice assertion when you perform background DFU? I meant to ask if you could double-check if the Softdevice backend is indeed used because the screenshot you posted earlier shows it's not.