BLE lost messages

[NikTheNordicUser]

Hi, as part of my project i have 2 nordic 52dks one as a pheripheral (sending) and on as a client (recieving). where i am sening a buffer of 8, in the order

buffer[0] = 10

buffer[1}= X gyro lsb

buffer[2] = X gyro msb

buffer[3] = y gyro lsb

buffer[4] = y gyro msb

buffer[5] = z gyro lsb

buffer[6] = z gyro msb

buffer[7] = 36   //terminator $

however sometimes i seem to lose a byte over ble such that the next byte received will be less and hence the order is correupted thus making processing rather and unpredictable for a large sample size like 1000000 samples.

how may i ensure that my ble settings are correct such that i ensure to limit this issue.

my code was based of the examples ble_app_uart and ble_app_uart_c for the peripheral and client respectivly.

thank u in advance 

[Karl Ylvisaker]

NikTheNordicUser said:

i finally understood apologies for taking so long...

I am glad to hear that, no need to apologize! :) 

NikTheNordicUser said:

ok so my problem at the moment is that the mcu is resetting after some time and this is the code i have and the debug terminal (it gets stuck on a NRF_BREAKPOINT_COND)

NikTheNordicUser said:

however after sometime running the reciveing nrf52Dk (client) seems to reset and im unsure why

Yes, this indicates that a non-NRF_SUCCSS error code is passed to an APP_ERROR_CHECK, as previously mentioned. Please confirm that you have understood what I am saying here - if you do not, I will attempt to explain it more explicitly. 

NikTheNordicUser said:

hope that the images are clear.

Now we are seeing the logging, and the detailed error message - great!
You are getting an ERROR_NRF_RESOURCES at line 984 of main.c.
What function is being called at line 984 of main.c?

I also notice two other small things in the picture you provided:
1. You are using nrf_delay_ms seemingly alot - is there a particular reason for this?
I would recommend against using nrf_delay to meet timing requirements, because it is not an accurate timer, and it wastes all the CPU cycles of its duration.
2. You seem to use blank spaces in your path - this is not a problem on windows machines, but could prove to be a problem for non-windows machines or tools/applications not originally made for windows. To avoid any such issue in the future I would recommend that you do not use blank spaces in your paths.

These two last points are small observations on my part, that has nothing to do with your current issue - so there is no immediate need to do anything about it, I just thought I should mention it to hopefully save you from future headaches.

Best regards,
Karl

[NikTheNordicUser]

Karl Ylvisaker said:

Yes, this indicates that a non-NRF_SUCCSS error code is passed to an APP_ERROR_CHECK, as previously mentioned. Please confirm that you have understood what I am saying here - if you do not, I will attempt to explain it more explicitly.

yes i understood now, thank you

Karl Ylvisaker said:

Now we are seeing the logging, and the detailed error message - great!
You are getting an ERROR_NRF_RESOURCES at line 984 of main.c.
What function is being called at line 984 of main.c?

i changes some of the code and the error is now at line 911 and at this point i have the funcction app_error_chcek

Karl Ylvisaker said:

1. You are using nrf_delay_ms seemingly alot - is there a particular reason for this?

ideally i dont have any delays however by having a large enouugh delay it results in a less probability of the client mcu resetting.

what im not understanding is that the code im alteringis the pherihperal code but it seems that the client is the one being effected and resetting 

[NikTheNordicUser]

in my situation, ideally i would like to eliminate delays such that i have the following system:

1. fill up a buffer  with sensor readings having 241 bytes 

2. transfer using ble

3. wait for the ble event to happen using an interrupt (unsure which and how to use it)

4. in the meantime that the send is happing i fill up another buffer with sensor readings

this will thus result in a perfect harmony and would probably be the most efficient.

i think that the interupt of a ble tx ready is called BLE_GATTS_EVT_HVN_TX_COMPLETE but im not sure where to place it and how to use it unfortunetly

[NikTheNordicUser]

and maybe i could somehow ensure that the tx buffer of the ble is empty such that i dont ever overfill and lose data

[Karl Ylvisaker]

NikTheNordicUser said:

yes i understood now, thank you

Great! Thank you for confirming :) 

NikTheNordicUser said:

i changes some of the code and the error is now at line 911 and at this point i have the funcction app_error_chcek

Yes, and which function return the error code that fails this APP_ERROR_CHECK? 

NikTheNordicUser said:

ideally i dont have any delays however by having a large enouugh delay it results in a less probability of the client mcu resetting.

This is just treating the symptoms of the error - we should instead focus on identifying and resolving the root of the error itself.

NikTheNordicUser said:

what im not understanding is that the code im alteringis the pherihperal code but it seems that the client is the one being effected and resetting 

Is the client encountering any errors? Are you saying that the code we are looking at right now is for the peripheral - but that the resetting happens on the central, and not on the peripheral?

NikTheNordicUser said:

this will thus result in a perfect harmony and would probably be the most efficient.

i think that the interupt of a ble tx ready is called BLE_GATTS_EVT_HVN_TX_COMPLETE but im not sure where to place it and how to use it unfortunetly

NikTheNordicUser said:

and maybe i could somehow ensure that the tx buffer of the ble is empty such that i dont ever overfill and lose data

Calling ble_nus_data_send queues data for sending as a notification during the next connection event. However, if you try to queue too many notifications too fast, the ble_nus_data_send function will return NRF_ERROR_RESOURCES, indicating that its buffer is full, and that the call to queue data failed.
You may then use the BLE_GATTS_EVT_HVN_TX_COMPLETE event to know when a notification successfully has been sent - meaning that you may now queue another notification for transfer, because it is now room in the buffer.

It is not really an issue to get the NRF_ERROR_RESOURCES, it just means that the call to queue data for transfer failed because the buffer is full. The returned error code lets us know that the program can not proceed as usual - instead, we must do some sort of error handling to bring the application back on track.

Best regards,
Karl