Fatal Error after sending notification

[Toran613]

Hey Guys,
currently, I am working on my masterthesis. I have to develop an mobile application which comminicates with the nordic board via BLE. I know that there is an existing application from nordic but I had to implement some extra features. The example I use is the ble_peripheral_uart example. According to measure my traffic I am using Docklight. 

My issue is that always when I try to send a notification with docklight to my application (Notification is enabled) my embedded studio crashes and I get a fatal error. Writing messages from the app to the board is possible. I can see this on docklight. 

The confusing point is that when I started to write messages and send notifications it worked. But one day I tried it again and this error appeared, which is really annoying because I haven´t changed a single line of C-Code from the example. I tried to run a new version from the code, I tried to use different versions from my android studios code, I ran the code on several computers I changed the eval board, I changed the UART-Module I am using, I reinstalled the software - nothing worked.

I noticed that it is possible to send notification as long as I send only one letter or number. When I send more letters or numbers or add \n my code crashes. Obviously, it is a memory issue but I don´t understand why it worked at the beginning. 

Can you give my some advices?

Kind Regards,
Thomas

[Einar Thorsrud]

Toran613 said:

So a solution could be to change HFINT to HFOX.

Yes.

Toran613 said:

I read that I have to set NRF_CLOCK->TASKS_CTART=1 and NRF_CLOCK->TASKS_LFCLKSTART=1 but this is not correct, I guess. It did not work...

You are right, this is not correct in this case. You write that you are using BLE, so I assume you have a SoftDevice running. In that case, the SoftDevice is responsible for configuring the clocks. Therefore, you need to either use SoftDevices APIs directly, or use the clock driver, which use the SoftDevice APIs when a SoftDevice is in use. If you use the clock driver, this always works well. However, if you do not have any other code that use the clock driver to control the HF clock (some drivers and libraries do that internally).

If you do this without the clock driver, then you can simply request the HFXO by calling sd_clock_hfclk_request(). If you don not care about current consumption you can leave it on. If you want to optimize current consumption, you should call sd_clock_hfclk_release() when you no longer need an accurate HF clock.

If you want to or has touse the driver, then you call nrf_drv_clock_hfclk_request() when you need an accurate HF clock and nrf_drv_clock_hfclk_release() when you no longer need it. Note that you also need to call nrf_drv_clock_init() at startup, and configure the driver in sdk_config.h. See for instance <SDK17.1.0>\examples\peripheral\usbd\main.c for an example of this.

[Toran613]

I called this function by putting hfclk_start into the function nrf_drv_clock_init(). The function hfclk_start includes the function sd:clock_hfclk_request(). As you told me, I am calling the init in my main.c. Unfortunatly it didnt solve my issue. Is there something else I can try? I have to make it work...I need it for my masterthesis.
Kind Regards,
Thomas

[Einar Thorsrud]

Hi Thomas,

Is the situation now that you ensure that you use the HFXO but still you get framing errors on the UART?

And is it still the case that you only see this safter sending a BLE notification? If so that is a bit odd, as UART and BLE should be independent (though you are sending the same data). Have you tested what happens if you comment out the code that actually sends the notification over BLE but keep the UART part? Do you still see the same issue? I believe it would make sense to try to handle this issue in a small application that focuses only on the UART part first, as that seems to be the problem. That way we avoid other details which may just get in the way of understanding and fixing the issue.

Have you double checked that you use the same baud rate configuration, flow control configuration etc on the nRF as on the other device?

Do you have a logic analyzer you can use to observe the UART traffic?