Porting nRF52833 code to BL653

[Jhonny23]

Hi,
I have a firmware that runs well on nRF52833 dev kit (SDK 17.02) and I am trying to port it to a Laird BL653 dev kit.
The firmware has a bootloader and it can perform DFU over Bluetooth.

The main difference between the nRF52833DK and the BL653 board is that the BL653 module does not use a crystal so I changed the following in sdk_config.h:


NRF_SDH_CLOCK_LF_SRC 0
NRF_SDH_CLOCK_LF_RC_CTIV 16
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
NRF_SDH_CLOCK_LF_ACCURACY 1
NRFX_CLOCK_CONFIG_LF_SRC 0
CLOCK_CONFIG_LF_SRC 0

If I apply these changes to the nRF52833DK it works fine.


After loading bootloader and softdevice on BL653, I can connect to DFU_Targ and send the ZIP package.
It all works fine until I power cycle the board, then Bluetooth stops advertising (but the microcontroller still executes my code).
The only way to restore the Bluetooth is by pressing the reset button.
Can anyone suggest where I should focus my attention?

I am quite new to Nordic devices so for this first project I hired a developer which did a good job but has not been able to help me with this issue.

[awneil]

Jhonny23 said:

Can anyone suggest where I should focus my attention?

Use the debugger to step through your code and see where it's going wrong.

As you have a working and a non-working version, you can compare the two - see where they differ...

Jhonny23 said:

I apply these changes to the nRF52833DK it works fine

Have you checked that it isn't still actually using the crystal ?

[Jhonny23]

awneil said:

Have you checked that it isn't still actually using the crystal ?

INTERESTING UPDATE:

I checked the pca10100 schematic and noticed that the LF crystal is connected through two solderbridges (SB1, SB2) that are normally closed.
You can disconnect the LF crystal by cutting the track on SB1 and SB2.

The BL653 dev kit is similar but the solder bridges are normally open.

Instead of cutting tracks on the pca10100, I decided to connect the LF crystal on the BL653 dev kit.
Both boards can now use the LF crystal oscillator.

This is the result of my testing:

1) Before changing the firmware settings, I checked the crystal signal with a scope on both boards.
- The crystal is not oscillating
- pca10100 works fine
- No changes to the behaviour of BL653. Bluetooth works only after pushing the reset button (or starting a debug session)

2) Restored "standard" (see below) clock settings on bootloader and loaded bootloader + softdevice S140
- The LF crystal is oscillating at ~32.76kHz on both boards
- Bluetooth is advertising as DFUTarg on both boards.

NRF_SDH_CLOCK_LF_SRC 1
NRF_SDH_CLOCK_LF_RC_CTIV 0
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
NRF_SDH_CLOCK_LF_ACCURACY 7
NRFX_CLOCK_CONFIG_LF_SRC 1
CLOCK_CONFIG_LF_SRC 1

3) Compiled firmware with "standard" clock settings, generated Zip file and performed DFU over Bluetooth.
- The LF crystal is oscillating at ~32.76kHz on both boards.
- pca10100 works fine
- No changes to the behavior of BL653. Bluetooth only works after pushing the reset button (or starting a debug session)

[Amanda Hsieh]

Hi Francesco,

In your case, the module BL653 should have a 32MHz crystal included already (To be able to use the radio the board needs 32MHz crystal anyway). It only missing the LFCLK 32kHz crystal. You should modify

NRF_SDH_CLOCK_LF_SRC 0
NRF_SDH_CLOCK_LF_RC_CTIV 16
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
NRF_SDH_CLOCK_LF_ACCURACY  1

Try to fully erase the chip. Open a terminal (cmd) and write: nrfjprog --eraseall

What is your updated application? Does it able to run before/without DFU? If not, are you able to make other ble applications run on BL653 dev kit, like the ble_app_uart?

-Amanda H.

[Jhonny23]

Hi Amanda, thanks for your answer.

I have modified those parameters but I had no luck.

Then I connected the LFCLK crystal and reverted the parameters (see my post above) but the problem is still present. My code is executed but Bluetooth does not advertise until I push the reset button.

I have also tried erasing the chip, no luck.

The only way to get it working are:

- pressing the reset button

or

- running a debug session

or

- after loading the code via DFU_Targ

All the actions above are in fact resetting the chip, so I started thinking it could be something related to noise or voltage rise time at power up so I tried to power the board while holding the reset button.

Even in this case I had no success.

- The BL653 dev kit works well as DFU_Targ but it shows problem when I load my firmware.

- The same code works great on nRF52833DK

- Examples provided by Nordic (EG: ble_app_uart) work perfectly on BL653 dev kit

What could be the problem with this BL653 dev kit? Now that I have connected the LFCLK it should work exactly as the nRF52833DK. Am I missing something?

[Amanda Hsieh]

Hi Francesco, 

It is strange if it works after a soft reset but not after the power-on reset.

Jhonny23 said:

- Examples provided by Nordic (EG: ble_app_uart) work perfectly on BL653 dev ki

I would suggest you use SDK examples like  ble_app_template or ble_app_uart as the base if they can work on the BL653 dev kit. 

-Amanda H.

[awneil]

Jhonny23 said:

What could be the problem with this BL653 dev kit?

That's a Laird product, isn't it?

https://community.arm.com/developer/ip-products/system/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault

So you'd need to contact Laird for support with their dev kit

[Howerd]

Hi Jhonny23,

I found this blog post when trying to fix a similar problem - it could also solve your problem...

I was using the Segger IDE to program a Laird BL653 module on a customer's board - I was able to connect to it via Bluetooth - once. After doing an "--eraseall" command it never advertised itself over Bluetooth again.

Looking at the armgcc Makefile showed that when programming the application hex file there is a 

"--sectorerase" option. I have not found a way to specify this option within the Segger IDE.

You can use the nRFconnect command line tools and a Windows batch file :

REM nRF52833 firmware load script 
REM Put this file here : ...\nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral\MyApp
del log.log
nrfjprog.exe -f NRF52 --log -v
nrfjprog.exe -f NRF52 --log --ids
nrfjprog.exe -f NRF52 --log --expand --ids
nrfjprog.exe -f NRF52 --log --recover
nrfjprog.exe -f NRF52 --log --deviceversion
nrfjprog.exe -f NRF52 --log --eraseall
nrfjprog.exe -f NRF52 --log --program ..\..\..\components\softdevice\s113\hex\s113_nrf52_7.2.0_softdevice.hex
nrfjprog.exe -f NRF52 --log --program .\pca10100\s113\ses\Output\Debug\Exe\MyApp.hex --sectorerase
nrfjprog.exe -f NRF52 --log --rbp ALL
nrfjprog.exe -f NRF52 --pinreset

It seems that the order of events is

1. erase all

2. program the softdevice

3. program the application hex, specifying only erase the necessary sectors ( --sectorerase )

So it looks like programming the softdevice also programs something else (UICR?) that is erased by certain types of erase.

I hope this helps :-)

Cheers,

Howerd