Build and Run with SEGGER Embedded Studio (SES) v6.20a on nRF5 SDK 17.1.0 and S140 7.2.0 on nRF52840

[Casper Kronborg Pedersen]

Hi DevZone,

I have recently updated:

• nRF5 SDK to 17.1.0 from 15.3.0
• S140 to 7.2.0 from 6.1.1
• SES to v6.20a from 4.16

The SoftDevice now fails to initialize when using the "Build and Run" option with SES.

The code initializes without issue if I:

• Use Programmer v2.3.3 from nRF Connect for Desktop v3.10.0
• If I Power Cycle the hardware after each flash of the .hex files
• If I "Build and Debug" with SES

Is this a known issue, and could it potentially be a timing issue?

Code that fails:

void ble_stack_init(void)
{
    ret_code_t err_code;

    err_code = nrf_sdh_enable_request();
    APP_ERROR_CHECK(err_code);

    // Configure the BLE stack using the default settings.
    // Fetch the start address of the application RAM.
    uint32_t ram_start = 0;
    err_code = nrf_sdh_ble_default_cfg_set(BLE_CONN_CFG_TAG, &ram_start);
    APP_ERROR_CHECK(err_code);

    // Enable BLE stack.
    err_code = nrf_sdh_ble_enable(&ram_start);
    APP_ERROR_CHECK(err_code);

//    // NO OBSERVERS AT THIS POINT 
//    // Register a handler for BLE events.
//    NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
}

Specifically the call to nrf_sdh_enable_request() returns with error code NRF_ERROR_INVALID_STATE (0x00000008).

This should mean that the SoftDevice is already initialized when reading the documentation. However, preceding the nrf_sdh_enable_request() call with a nrf_sdh_is_enabled()

tells me that it is not.

Comparing with example projects:

I have compared to the example projects given in SDK 17.1.0, and the initialization code for the BLE stack seems unchanged between versions 17.1.0 and 15.3.0. 

Also, I have tried building and running the peripheral example from SDK 17.1.0 "usbd_ble_uart_freertos" both on our hardware and an nRF52840-DK, which fails with the same error code.

So, even with code directly from the SDK and on multiple hardware the issue is the same.

Thanks in advance.

Br. Casper

[Edvin]

Hello Casper,

After discussing this with a colleague, we concluded that the issue is not related to the nRF, the SoftDevice or the SDK. It looks like a bug in the Segger Embedded Studio's debugging firmware. The build and run doesn't reset the nRF properly, but it is trying to do some "hack" by only resetting the vector table and start the execution again, without actually resetting the chip. The reason this is only triggering now (after your port), and not in the old SDK, and as far as I know (but I may be wrong), not in the other non-freertos examples has to do with timing differences in how the threads are started. 

I agree that it is a bug, and an inconvenience, but I don't think Nordic will reach out to Segger and ask for a patch. It should not cause any issues during production, or for the final product. 

As you say, the issue is not present "the first time you press build and run", and the reason for this is that this time, SES will actually program the chip, and then reset it properly after. The second time you press build and run, it will just read the flash to see that it is already programmed, and then it will do the buggy reset thing. 

For your convenience, you can add this .bat file to your usbd_ble_uart_freertos folder, and run it whenever you want to flash your new FW. 

Fullscreen flash.bat Download

nrfjprog --program pca10056\s140\ses\Output\Release\Exe\usbd_ble_uart_freertos_pca10056_s140.hex --verify --sectorerase --reset

(change it if you want to flash the debug build instead.

You can then run it from a command line in that folder. 

Best regards,

Edvin

[Casper Kronborg Pedersen]

Hi Edvin,

Thank you for getting back to me so quickly.
Ok, as long as the issue is just caused by SES not resetting the chip properly then there should be nothing to worry about for the final product as you say.

Thank you for the .bat file.

Would it make sense to make this thread public again in case anyone else is having similar experiences?

Br. Casper

[Edvin]

Hello Casper, 

As long as you don't have any sensitive information in this ticket, it is perfectly fine to open it to public. As you say, it may help someone with similar problems. 

I don't have the possibility to open private tickets to public (only the other way), so you would need to do that.

Best regards,

Edvin