NRF52840 unable to initialize the Bluetooth stack without the programmer.

[Vasav Shah]

Hey!

I have an isp1807 test board, which uses an nrf52840 chip, and an isp1p807 programmer (ISP130603E). Currently, my code is written using the nrf52 sdk v17. When I am connected and powered off the programming board, the test board boots up correctly and is able to connect to a tablet via Bluetooth. However, when I power the test the board from an external power supply, the mcu crashes on Bluetooth initialization. I was wondering if anyone has had issues powering the nrf52840, off an external power supply? 

Thanks for your help!

Vasav  

[Hung Bui]

Hi Vasav, 

I suspect there could be something wrong with the clock source configured for the chip. 

Could you give more information on how you configure the LFCLK in sdk_config.h (NRF_SDH_CLOCK_LF_SRC) 

You may want to test setting the NRF_SDH_CLOCK_LF_SRC to RC. Just in case there could be an issue with the 32kHz crystal on the module. 

Do you have any error code when the device crashed, do you know at which line it crashed ? I assume you are using S140 v 7.2.0 ? 

[Vasav Shah]

Hi Hung,

I have the NRF_SDH_CLOCK_LF_SRC set as NRF_CLOCK_LF_SRC_XTAL currently. I tried switching it to RC however that resulted in the Bluetooth stack not being initialized properly at all, even with the programmer board. The error code for the RC version was 7 and the error resulted in when calling the nrf_sdh_enable_request() function. 

When I had set the LF_SRC to XTAL, the Bluetooth stack failed to initialize nrf_sdh_enable_request() as well. I do not have the error code for this since I only notice this error when I'm not connected to the programming board. 

We are using the nrf52sdk v 16.0.0, with S140 of v7.0.1. 

Do you think it would be beneficial to upgrade the sdk to v17? 

Thank you for your help!

Vasav 

[Hung Bui]

Hi Vasav, 

If you look at the description of sd_softdevice_enable() you can find error 7 is:

* @retval ::NRF_ERROR_INVALID_PARAM Invalid clock source configuration supplied in p_clock_lf_cfg.

So there could be something wrong in the configuration of clock_lf_cfg. Please try : 

NRF_SDH_CLOCK_LF_RC_CTIV = 16 

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV = 2 

and NRF_SDH_CLOCK_LF_ACCURACY = 0. 

I don't think updating to SDK v17 and S140 v7.2 would help as they are very similar to SDK v16 and S140 v7.0.1 

[Vasav Shah]

Hi Hung,

I tried to change the sdk_config to the parameters you suggested and it still didn't make a difference. I also noticed that it doesn't actually return an error from the nrf_sdh_enable_request. The program is either hanging during the function call or crashing. 

Based on what the function does, I think the only way it can get hung is if the Critical region is never exited? Do you have any suggestions as to what can cause this?

Also, is there a reason why you think the clock configuration is incorrect?

Also, I think the link I have here is similar to the issue I am facing, however, the chipset is different. Was there a specific workaround for the nrf52840 chip that I might not have? (+) sd_softdevice_enable does not return - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

Thanks for your help!

Vasav  

[Hung Bui]

Hi Vasav, 

The nRF52840 doesn't have the issue that require errata_108. So it should be something else. 

In addition SDK v17.x should have all the errata needed for the specific chip implemented. 

Which firmware did you use to test? have you tried to test with the default BLE example in the SDK ? 

In the application do you enable DCDC ? Seems that the isp1807 does have DCDC support components. 

Could you send the schematic of your test board ? 

If you test with other board/module  do you see the same problem  ? 

Could you try to do what Kenneth suggested in this case to start the LFCLK manually before the softdevice ? 

[Vasav Shah]

Hey Hung,

I am currently using the firmware that I wrote specifically for our application. The starting point for our firmware was from the ble_app_uart example however there have been a lot of changes since then. I flashed the MCU with the example code (ble_app_uart), and it was able to start up properly. This makes me believe that there must be something weird going on in our firmware.

I currently do not enable DCDC power converters because based on my reading I thought the board should be able to still work the same way except it would consume less current with the DCDC enabled.

To clarify your last question, my current setup is using the test board provided by insight (the schematic is here New Output (insightsip.com)). I can share the schematic with you for our custom board, but I would rather not post that in a public forum, is there a way I can send it to you directly? Also, I have tried this on multiple test boards and noticed the same issue. This again seems to point to an issue in my firmware.

Last night, I decided to put pull-up resistors on P0.8 (which I believe is used as RX for the UART), and with this in place, we were able to see the board start up normally. In the past, we have noticed weird behavior with P0.6 and P0.8, but at the time I thought the problem was because there were conflicting pins in our hardware design and the UART init, so I had changed the pins used for our hardware to other pins, and that had seemed to solve the issue while we were using the programming board. Do you know why this pull-up resistor would solve our issue? I'm not satisfied with this solution yet, because I don't fully understand why it works and what the root cause of the problem is. Do you have any insight into this?

Finally, I did attempt what Kenneth suggested, and it did not make a difference.

Thanks!

Vasav

[Hung Bui]

Hi Vasav, 

We would need more debug information to find what exactly caused the issue. 

You mentioned that the CPU hung inside nrf_sdh_enable_request() please try to debug and find at which exact function it hung. 

I would suggest to turn off the functionality of your program gradually until you have BLE working again (if the stock example works that mean you can remove functionality of your application to match the stock example). You may want to move the softdevice initialization to the top of your application initialization calls. 

I suspect it may related to how you handle logging with your application. When you don't connect the device to PC maybe the board has buffer overflow or deadloop inside log module ? 

You mentioned that you changed the pins used for your hardware to other pins, could you let me know which hardware you connected to ? Which pins you used ? 

If your hardware support DCDC you can either choose to use DCDC or not, that shouldn't be a problem. 

[Vasav Shah]

Hi Hung,

So I narrowed down the exact error code to be NRF_FAULT_ID_SDK_ERROR, in the default app_error_fault_handler. I believe this function is passed in as a parameter for the sd_softdevice_enable function which is being called in the nrf_sdh_enable_request.

I thought the logging could've been an issue as well so I have disabled that by setting NRF_LOG_ENABLED as 0 in the sdk_config and the problem still persists. 

Hung Bui said:

You mentioned that you changed the pins used for your hardware to other pins, could you let me know which hardware you connected to ? Which pins you used ?

So when we had the issue with P0.6 and P0.8 it was the same set-up (test board (1ISP1807-LR-TB_B) provided by insight + programming board provided by insight (ISP130603E)). Using this hardware setup, I had configured the P0.6, P0.7 and P0.8 as GPIO pins and I was using the default nordic uart service in my firmware. I later learned that the nordic uart service configures P0.5 (RTS), P0.6 (TX), P0.7(CTS), and P0.8(RX) as UART pins. The conflict in the gpio pins and the uart pins would have been a problem so, I had changed the gpio pins to other pins which were not used. After doing this I think everything worked while I was connected to the ISP130603E board. The issue, I am facing now only occurs when I am not connected to this board. I hope this was more clear as to my setup and configuration. 

I will try and change up the init order to exactly match the init code and let you know.

Thanks for your help!

Vasav