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.

[Einar Thorsrud]

I see. Which exact SDK example project do you test with (e.g. <SDK17.0.2>\examples\ble_peripheral\ble_app_uart\pca10056\s140\ses\ble_app_uart_pca10056_s140.emProject)? And which exact toolchain version do you use (like SES 5.30a or something else)?

[George1515415]

We've tried multiple for example: <SDK17.0.2>\examples\ble_peripheral\ble_app_uart\pca10056\s140\armgcc\Makefile

gcc

GNU ARM toolchain

2019-q4-major

[Einar Thorsrud]

I see. Do you know the state of the reset pin (P0.18) of your custom HW? Is it by any chance connected to ground or left floating, or in any other state than tied to VDD? If so you should modify the Makefile by removing this line in order to disable pin reset:

CFLAGS += -DCONFIG_GPIO_AS_PINRESET

Note that you will need to do a full chip erase (nrfjprog -e) in order to have the changes take effect as this changes what is written to the UICR register (specifically the PSELRESET registers).

[George1515415]

The pin is pulled to GND with 1nF cap on all out designs. But I've tried adding the flag recompiled the project, did a mass erase, reflashed and it still won't start the application. I did a flash dump and verified that both the application and s140 are in memory. the s140 starts at 0x0 and app at 0x27000 for sdk 17.0.2.

I keep finding references to mbr settings and bootloader with references to s140. Just to clarify, do I need to create a mbr settings file and use a bootloader in order to run for example the ble_app_template? Or just in general do I need the mbr and bootloader to use s140 sd?

[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)?