Issue with Softdevice S140 on Arduino Nano BLE 33 board (nRF52840)

[Sebastien DRI]

Hi Folks,

I am getting in trouble with SoftDevice activation. Indeed, my application did not return from the "nrf_sdh_enable_request()" call, more precisely it hangs into the "sd_softdevice_enable".

I want to mention that I compile the S140 file within my application so I did not flash independently the Softdevice hex previously into my target. Maybe my linker script file is not OK or my sdk_config.h file

My questions are: Is it possible to flash in one shot softdevice + application ?if yes, how must be configured the linker script file?

I have also noticed that the "sd_softdevice_enable" function refers to a sd_softdevice_enable to a SVCALL so I suppose S140 must be flashed first in that configuration so my Arduino board must be in a hard fault reset state. Am I right?

Another file contains a pure C definition , it is located in the named "ser_softdevice_handler.c". Can it serve to implement Softdevice without in a single application file?

I know I ask a lot so I thank u a lot as well.

The best.

Seb

[bjorn-spockeli]

Hi Seb,  

I want to mention that I compile the S140 file within my application so I did not flash independently the Softdevice hex previously into my target. Maybe my linker script file is not OK or my sdk_config.h file

 The SoftDevice is a precompiled binary(hex file) and we provide the header files for the SoftDevice API that you compile into your application. So in order to use the SoftDevice you need to compile the headers into your application and flash the SoftDevice hex file to the nRF52840. 

My questions are: Is it possible to flash in one shot softdevice + application ?if yes, how must be configured the linker script file?

Below is the linker script for the ble_app_blinky application in our nRF5 SDK. You just need to place the application on the first flash page after the SoftDevice and then set the RAM origin according to the minimum RAM requirement stated in the S140 SoftDevice specification

 ble_app_blinky_gcc_nrf52.ld

I have also noticed that the "sd_softdevice_enable" function refers to a sd_softdevice_enable to a SVCALL so I suppose S140 must be flashed first in that configuration so my Arduino board must be in a hard fault reset state. Am I right?

 Correct. The SoftDevice API is implemented as SVCALLs so the S140 must be flashed to the nRF52840, otherwise the the SVCALL will just return and state that it could not find the SVC Handler of the SoftDevice.

Another file contains a pure C definition , it is located in the named "ser_softdevice_handler.c". Can it serve to implement Softdevice without in a single application file?

No, this is the serialization API that allows you to use the nRF52 SoCs as connectivity chips through a serial interface to another MCU. See Running a serialized application and Serialization for further documentation on serialization.

Best regards

Bjørn

[Sebastien DRI]

Thank u a lot.

Very clear explanations!

I have still some issue to run the ble_blinky  example.

I am currently flashing over a SAM -BA Bootloader (the one installed on my Arduino nano board) via USB serial.

I am also running teh blinky example using SDK 15.0.0 with the corresponding Softdevice (6.0.0).

However, it seems that nothing is happening (no Peripheral detected while scanning BLE).

I compile the ble_app_blinky with Keil environment (PCA10056 board) and everything is fine concerning linker script (ROM/RAM offset) and I also set up RC internal clock since the Arduino board does not have XTAL.

So, in a nutshell, I first flash Softdevice with "Bossac" command then perform hex2bin for the blinky app and then flash it again with "Bossac".

Did u suspect something wrong in my procedure? Is Bossac recommended in that case? Or maybe I am missing something 

to make compatible PCA10056 board with the Arduino Nano BLE one (pin configurations or sdk_config.h).

[Sebastien DRI]

I have also tested with the XTAL clock source configuration, not successful

[bjorn-spockeli]

Sebastien DRI said:

I compile the ble_app_blinky with Keil environment (PCA10056 board) and everything is fine concerning linker script (ROM/RAM offset) and I also set up RC internal clock since the Arduino board does not have XTAL.

Can you post the section of sdk_config.h with the clock source settings for the SoftDevice? 

Sebastien DRI said:

So, in a nutshell, I first flash Softdevice with "Bossac" command then perform hex2bin for the blinky app and then flash it again with "Bossac".

Did u suspect something wrong in my procedure? Is Bossac recommended in that case? Or maybe I am missing something 

to make compatible PCA10056 board with the Arduino Nano BLE one (pin configurations or sdk_config.h).

 I am not that familiar with bossac, but as far as I understand its the commandline version of the Bossa flash programming utility for Atmel's SAM family of flash-based ARM microcontrollers. So im not sure that you can use that with Nordic devices. 

If you flash the SoftDevice hex, then that should be placed correctly, but why do you convert the ble_app_blinky hex to bin and then flash the bin if you can flash hex files? If you flash the bin then you need to make sure that its placed on the first flash page after the SoftDevice

We have our own commandline flash programming utility tool  called nrfjprog, see the nRF5x Command Line Tools. 

Looking at the schematics of the Arduino Nano 33 BLE, found here,  I see that the SWD interface is exposed. Do you have a a Jlink programmer or a Nordic development kit? If you do then you can use nrfjprog to flash the SoftDevice 

[Sebastien DRI]

8880.sdk_config.hThank u again Bjorn.

You are right, I must buy a J-link to perform those operations.

Bossac executable only understands *.bin files so that's why I convert the generated hex files.

This is the end when flashing mbr + sofdevice on the arduino board using bossac software:

Then, I flash the firmware application starting at 0x26000.

Here is a snapshot of my linker script file:

So I have started flashing from 0x26000 which is next sector.

Another point is that the arduino Board only work when application is located at offset 0x10000 so maybe Bootloader reset handler is configured to jump at that address.

I found very strange that Arduino has set up such king of default configuration since 0x10000 does not allow a Softdevice normal use.

Maybe I miss something.

Is there a way to modify this offset address in the bootloader in order to jump to the right offset?

I also noticed that an application without softdevice flashed , so running from 0x10000 offset adress, shall have the RAM_NVIC configured so that it can work properly. It's different compared to other examples which use ISR vector table but  I think it's different things appart from my initial problem.

In fact, I do not master how works the initilal sequence from hard reset to application start and what is involving this fixed offset address in flash memory.

To me, in a normal sequence with softdevice (after single press on hard reset) we shall have MBR->Softdevice-> Firmware application

and on a double tap reset (MBR-> Bootloader)

I certainly miss something important!

[bjorn-spockeli]

Sebastien DRI said:

You are right, I must buy a J-link to perform those operations.

 You can use a nRF51, NRF52 , nRF52840 and nRF52833 DK as a Jlink Porgrammer/Debugger for development purposes(not production programming). So if this is only for development, then a Nordic DK is more afordable than a Jlink probe. 

Sebastien DRI said:

Bossac executable only understands *.bin files so that's why I convert the generated hex files.

This is the end when flashing mbr + sofdevice on the arduino board using bossac software:

 Ok, Is this the complete log? The MBR and SD should be flashed from 0x0000 and upwards to 0x26000. 

 

Sebastien DRI said:

Then, I flash the firmware application starting at 0x26000.

Here is a snapshot of my linker script file:

So I have started flashing from 0x26000 which is next sector.

I am a bit unsure if its OK to place the RAM_NVIC and RAM_CRASH_DATA sections  before the the RAM section. Have you checked which ram start value that sd_ble_enable() function returns?

 

Sebastien DRI said:

Another point is that the arduino Board only work when application is located at offset 0x10000 so maybe Bootloader reset handler is configured to jump at that address.

I found very strange that Arduino has set up such king of default configuration since 0x10000 does not allow a Softdevice normal use.

Maybe I miss something.

Is there a way to modify this offset address in the bootloader in order to jump to the right offset?

 When you refer to the bootloader you are talking about the Arduino bootloader right? Yes, I agree that it sounds weird that the application must be placed at 0x10000 if the Nano 33 BLE board supports BLE using the SD. 

The Nordic Bootloader will jump to 0x1000, which is the reset handler of the SoftDevice, which will do som initialization before jumping to 0x26000 where the application is located.  I do not know how to modify the Arduino bootloader.  

 

Sebastien DRI said:

I also noticed that an application without softdevice flashed , so running from 0x10000 offset adress, shall have the RAM_NVIC configured so that it can work properly. It's different compared to other examples which use ISR vector table but  I think it's different things appart from my initial problem.

In fact, I do not master how works the initilal sequence from hard reset to application start and what is involving this fixed offset address in flash memory.

To me, in a normal sequence with softdevice (after single press on hard reset) we shall have MBR->Softdevice-> Firmware application

and on a double tap reset (MBR-> Bootloader)

 Again I can only provide insight on the Nordic Bootloader. The MBR will branch to a bootloader if its address is stored in UICR(0x10001014) and then the bootloader will jump to the SoftDevice, which in turn will jump to the application.

If no bootloader address is stored in UICR, then the MBR will jump directly to the bootloader. 

Best regards

Bjørn

[Sebastien DRI]

Thank you again for your answers and advices.

bjorn-spockeli said:

 Ok, Is this the complete log?

No it is not and yes it starts from 0x00000000

bjorn-spockeli said:

Have you checked which ram start value that sd_ble_enable() function returns?

No, but I will check if the "sd_ble_enable" return since for instance I have deactivated BLE in the main application.

I hope that RAM_NVIC & RAM_CRASH_DATA sections are detected by Softdevice so that it can shift the application start adress accordingly taking into account them.

What do you suggest in that case? Specify the Softdevice ram section within linker script?

bjorn-spockeli said:

When you refer to the bootloader you are talking about the Arduino bootloader right?

Yes, i am talking about the SAM-BA factory bootloader of which I have recently checked the code and I have discovered they do not automate app start adress calculation.

Consequently I'll load a different bootloader (the Adafruit_nRF52_Bootloader compatibles with nano 33 board) as soon as I'll receive the programming board. Hope will be fine once done.

Thank you again for your support. It helps me to under quickly how it works.

Let's be in touch later if you want to conclude this chapter.