I am using a code similar to App_uart_C from SDK17.02 - central sending data over uart to another peripheral.
After 30-60 sec, the operation stops probably due to an error in the UART and I need to reset the chip
How can I handle UART errors ? I don't mind loosing data - but I cannot stay with the software crashing
Thanks
Avi
Hi,
It does not sound like a very reliable way to resolve the issue with a delay, and this could also increase the current consumption of your device.
If you can explain where the error occurs, and what the error is, I can help you find a better solution. If the chip "stops", it is most likely ending up in the error handler, because an error code was passed to APP_ERROR_CHECK() macro, and you have built the application in debug mode. You do not have to pass all error codes to this macro, it is fully up to you how you handle an error. For instance, if you get a NRF_ERROR_NO_MEM error from a call to app_uart_put(), you can filter this error and tell your application to retry the operation at a later point.
Best regards,
Jørgen
Have you considered adding HWFC pins to the UART in your application? If you are not able to process the FIFO fast enough, the incoming stream of data may overflow the UART, causing an error.
You can try to remove the APP_ERROR_CHECK in APP_UART_FIFO_ERROR case in uart_event_handle(). This will ignore any OVERRUN/PARITY/FRAMING/BREAK errors from the UART peripheral, which may lead to data loss.
case APP_UART_FIFO_ERROR:
//APP_ERROR_HANDLER(p_event->data.error_code);
break;
I cannot use the HWFC since my ext processor doesn't support it.
I removed the //APP_ERROR_HANDLER(p_event->data.error_code);
And still the transfer is stuck after few seconds (about 1000 lines of 15 chars each).
The only way to recover is via hard reset
Please look at this part of the code:
do
{
err_code = central_string_send(data_array, index);
if ( (err_code != NRF_ERROR_INVALID_STATE) && (err_code != NRF_ERROR_RESOURCES) )
{
//APP_ERROR_CHECK(err_code);
}
} while (err_code == NRF_ERROR_RESOURCES);
uint32_t central_string_send(uint8_t * p_string, uint16_t length)
{
return ble_nus_c_string_send(&m_ble_nus_c, p_string, length);
}
Anyway to improve it?
I build up a debugging environment based on 52840DK connected to a PC with Serial to input the streams. I can recreate the crash. Currently the last message on the RTT viewer is:
"<debug> nrf_ble_gq: Processing the request queue..."
I's appreciate some help on how to find the reason for crash and to fix it
Can you start a debug-session with your application and put breakpoints around to find out where the issue is happening? Note that you will have to restart the application once you hit a breakpoint, the softdevice will not allow you to single-step far into the application.
APP_ERROR_CHECK() will call app_error_handler(), where you should be able to determine the origin of the error.
I checked with SDK15.0 and the code is working without any delay
So, it may be easier to find the problem in SDK17.02 if you can explain what are the changes in:
UART, NUS or softdevice related to the problem I see.
I checked with SDK15.0 and the code is working without any delay
So, it may be easier to find the problem in SDK17.02 if you can explain what are the changes in:
UART, NUS or softdevice related to the problem I see.
It is very hard to say something about what changes in the SDK/softdevice that could cause this without knowing where the error happens. There are many modules involved in the example.
If you are not able to determine the source of the error through debugging, maybe you could upload the full project for me to reproduce/debug it for you?
Can I send it in private mail?
Hi Jorgen,
Did you get the code?
Thx
Avi
Please update if you got my code with the problem of SDK17.02 vs. SDK15
I received your code, but I have not found a solution for you yet. Will get back to you as soon as possible.