Enabling Softdevice fails in bootloader when trying to initialize multiple DFU transports

[Adam Gordon]

Hi,

I'm working on a bootloader that combines both the BLE and UART transport layers. We have custom hardware containing the nRF52832 chip running on SDK 15.3, and we're using softdevice s132 v6.1.1.

I started with the secure BLE bootloader example pca10040_ble_debug and then slowly added in the UART transport layer. I did this by first adding the file nrf_dfu_serial_uart.c to the project and then working through any errors when building in SES. Roughly, from memory, I think it involved the following additional changes to the project:

• Added these additional files:
  • nrf_dfu_serial.c
  • nrf_drv_uart.c
  • nrfx_uart.c
  • nrfx_uarte.c
  • nrfx_prs.c
  • slip.c
• Added these additional include paths:
  • ../../../../../components/libraries/slip
  • ../../../../../integration/nrfx/legacy
  • ../../../../../modules/nrfx/drivers/include

  • ../../../../../modules/nrfx/drivers/src/prs

• Merging the sdk_config.h files from both the pca10040_ble_debug and pca_10040_uart_debug example projects.

The project builds without errors, but when running, I do not see dfu_targ advertising, and timed out when trying to perform a DFU over UART using nrfutil. Debugging through the issue, the error occurs when trying to enable the softdevice when initializing the BLE DFU transport layer. I get the following debug printout:

<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 2)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00072000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> app: Failed to initialize transport 0, error 4096
<error> app: Could not initalize DFU transport: 0x00001000
<error> app: Received an error: 0x00000003!

Error code 4096 is "NRF_ERROR_SDM_LFCLK_SOURCE_UNKNOWN" which is "unknown LFCLK source". However, I don't think this is really the issue since it is set up the same way as always when bootloaders, softdevices, applications have had no issue running. Also, to further debug, I removed the file nrf_dfu_serial_uart.c from the project, cleaned, and then built again and the softdevice enabled without issue. I even saw dfu_targ advertising. Which means that the issue is with adding in the additional transport layer, but I don't know why it would cause an unknown LFCLK source error to occur.

Wondering if it was a global issue with having multiple transport layers, I edited the project file to list nrf_dfu_serial_uart.c first so it would be the first transport layer initialized and it initialized successfully with the following debug printout:

<info> app: Entering DFU mode.
<debug> app: 
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00072000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> app: 
<error> app: Could not initalize DFU transport: 0x00001000
<error> app: Received an error: 0x00000003!

Lastly, after doing a lot of research online, I noticed that a lot of other people's issues stemmed from FLASH or RAM size / placement. I tried changing the values but it did not have any effect. Nor do I think it's the issue since there was no suggesting in the debug printouts to change any of the RAM or FLASH values. But for the record, here are my values:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x80000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x10000
FLASH_START=0x72000
FLASH_SIZE=0xc000
RAM_START=0x200057b8
RAM_SIZE=0xa848

**NOTE: I also tried running the project on a DK board and the same issue happens.

Any suggestions or help would be much appreciated. Thanks.

[Edvin]

Hello,

Can you try to define DEBUG in your preprocessor definitions? It should use the app_error_handler() instead of app_error_handler_bare(). I suggest that you add the err_code to the app_error_handler() logging as well (I don't know why it is removed):

void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t * p_file_name)
{
    NRF_LOG_ERROR("error: %d, %s:%d", error_code, p_file_name, line_num);
    on_error();
}

What place in your code does it point to? 

Best regards,

Edvin

[Adam Gordon]

Hi Edvin,

Thank you for your reply! I defined DEBUG in my preprocessor definitions and added err_code to the app_error_handler and it gives the following output:

<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 2)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00072000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> app: Failed to initialize transport 0, error 4096
<error> app: Could not initalize DFU transport: 0x00001000
<error> app: error: 3, /My_Directory/nRF5_SDK_15.3.0_59ac345/examples/dfu/secure_bootloader/main.c:144

That points to the APP_ERROR_CHECK in main right after nrf_bootloader_init. The two lines look like this:

143:    ret_val = nrf_bootloader_init(dfu_observer);
144:    APP_ERROR_CHECK(ret_val);

It looks like error code 3 refers to NRF_ERROR_INTERNAL. Does that tell us anything? Thanks.

[Edvin]

Hello Adam,

Well, as you pointed out in your initial post, this refers to NRF_ERROR_SDM_LFCLK_SOURCE_UNKNOWN. 

Can you set a breakpoint at nrf_sdh.c on line 214 (ret_code = sd_softdevie_enable(...))?

What are your:

clock_lf_cfg.source
clock_lf_cfg.rc_ctiv
clock_lf_cfg.rc_temp_ctiv
clock_lf_cfg.accuracy

Not what you set them to above, but what are the numerical values when you hit line 214?

[Adam Gordon]

Hi Edvin,

That was a breakpoint I had previously set, however I only looked at the values I set them to. Unfortunately the numerical values when I hit line 214 are 0xff for all 4 values.

To double check, I went back and removed the file nrf_dfu_serial_uart.c from the project, cleaned and built, and at line 214 the values were what they were set to on lines 204-207.

[Adam Gordon]

I think we might be up against the flash limit of the nRF52. Without including nrf_dfu_serial_uart.c in the project we get the following build result:

Aka 512.5 kB of flash storage used.

WITH nrf_dfu_serial_uart.c included, we get the following results:

Aka 516.5 kB of flash storage used.

Is there a reason why in either case no error was thrown / nothing complained? I'm assuming this could be where the issue is coming from? If so, is there any way we could cut down on the size of flash needed while still keeping the dual transport layer functionality?

For the record, under Project Options > Code Generation > Optimization Level, I already have it on "Optimize For Size"

...assuming this is the issue. If not, please let me know what else I can try.