nrf52840 BLE not working

[George1515415]

Hi,

We have recently switched from using nrf52810 to nrf52840. Firmware porting went well until we tried using the BLE on nrf52840. No matter what we try the BLE will not start advertising. Even BLE examples in the SDK don't work ( tried ble_app_uart, ble_app_template,ble_app_hrs  ). When I flash softdevice (s140 provided in the sdk) and then the compiled example the BLE will not start. We never had these problems when working with the nrf52810 s112 sd. I have gone over the documentation and can't find any other reason why it will not work. All other peripherals (I2C, SPI, UART, even the proprietary ESB) works fine as long as I don't use the s140. The SDK version we used was 15.3.0. I've tried upgrading to 17.0.2  but the same result. The MCU seems to be unable to start the flashed FW with the s140 sd. Has anyone else ran into this issue?

Our board does not have an external crystal, but nrf52810 BLE worked fine on the internal RC osc. Has that changed?

[Einar Thorsrud]

Hi, 

The MCU seems to be unable to start the flashed FW with the s140 sd.

The typical reason for this is that the 32.768 kHz crystal is configured but not present. I see you write that you have changed this in sdk_config.h, but can you clarify which changes you have made in sdk_config.h? You should set NRF_SDH_CLOCK_LF_SRC to 0, NRF_SDH_CLOCK_LF_ACCURACY to 1, NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to 2 and NRF_SDH_CLOCK_LF_RC_CTIV to 16.

Have you done any debugging to see what happens? If you make a debug build and put a breakpoint in the start of you main function it would be interesting to see if it is reached. If it is not, the first thing you should double check is that you actually have programmed the  SoftDevice.

[George1515415]

I had NRF_SDH_CLOCK_LF_RC_CTIV set to 32 but I tried it with 16 and the same result. I have changed all of the other parameters you mentioned. During debugging the code starts to execute but when it reaches the SD_SOFTDEVICE_ENABLE function it jumps to 0xaca in the memory and stays there until the WDG triggers a reset. If the WDG is disabled it will hang there forever.

[George1515415]

Typo, I removed the flag.

[Einar Thorsrud]

I see. Then this is not the cause of the issue. One other thing, can you confirm that you program both the SoftDevice and the application? Can you show exactly how you do it (which commands in which order or similar)?

[George1515415]

I've tried multiple combinations and multiple different programs to flash ex:

nrfjprog -f nrf52 --program s140_nrf52_7.2.0_softdevice.hex --sectorerase

nrfjprog -f nrf52 --program nrf52840_xxaa.hex --sectorerase

I've tried switching the commands. I also tried openocd just to make sure it wasn't a problem with the nrfjprog, and used a different programmer

openocd -s $OPENOCD/tcl -f interface/stlink-v2.cfg -f target/nrf52.cfg -c init -c "reset init" -c halt -c "program  nrf52840_xxaa.bin verify 0x27000" -c reset -c exit

openocd -s $OPENOCD/tcl -f interface/stlink-v2.cfg -f target/nrf52.cfg -c init -c "reset init" -c halt -c "program s140_nrf52_7.2.0_softdevice.hex verify" -c reset -c exit

both failed.

[Nguyen Hoan Hoang]

You need to use mergehex to combine the softdevice and you hex into single hex before flashing it.

[Einar Thorsrud]

Hi,

What exmaple project did generate nrf52840_xxaa.hex?

This does not have to be the problem, but if the application you program has data in the MBR page (which applies to for instance bootloaders form some SDK versions) you need to either use mergehex as suggested (then make sure to update to the latest nRF Command Line Tools due to a mergehex bug), or program without --sectorerase. A different approach would then be:

nrfjprog -e
nrfjprog -f nrf52 --program s140_nrf52_7.2.0_softdevice.hex
nrfjprog -f nrf52 --program nrf52840_xxaa.hex