Problems with UART in 52840

RE: Problems with UART in 52840

Avi — Tue, 29 Dec 2020 19:27:16 GMT

After several attempts to focus on the exact reason for the failure, I am now sure that it is due to RX error that is causing an error which is non recoverable.

I am streaming data into the chip via UART interface at 38K (not able to use FC). Is there a recommendation on how to handle such error? i.e. any signals from the uart driver that can be used in advance?

RE: Problems with UART in 52840

Jørgen Holmefjord — Wed, 09 Dec 2020 14:06:40 GMT

I received your code, but I have not found a solution for you yet. Will get back to you as soon as possible.

RE: Problems with UART in 52840

Avi — Wed, 09 Dec 2020 12:09:37 GMT

Please update if you got my code with the problem of SDK17.02 vs. SDK15

RE: Problems with UART in 52840

Avi — Mon, 07 Dec 2020 10:52:51 GMT

Hi Jorgen,

Did you get the code?

Thx

Avi

RE: Problems with UART in 52840

Avi — Fri, 04 Dec 2020 10:30:54 GMT

Can I send it in private mail?

RE: Problems with UART in 52840

Jørgen Holmefjord — Fri, 04 Dec 2020 10:15:56 GMT

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?

RE: Problems with UART in 52840

Avi — Fri, 04 Dec 2020 07:11:44 GMT

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.

RE: Problems with UART in 52840

Jørgen Holmefjord — Thu, 03 Dec 2020 09:37:54 GMT

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.

RE: Problems with UART in 52840

Avi — Thu, 03 Dec 2020 08:25:01 GMT

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

RE: Problems with UART in 52840

Avi — Wed, 02 Dec 2020 20:57:26 GMT

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?

RE: Problems with UART in 52840

Avi — Wed, 02 Dec 2020 20:55:35 GMT

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

RE: Problems with UART in 52840

Jørgen Holmefjord — Wed, 02 Dec 2020 20:40:43 GMT

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;

RE: Problems with UART in 52840

Avi — Wed, 02 Dec 2020 20:13:05 GMT

Indeed, after more testing, it was not a reliable solution.

I am streaming data via the UART at 38K from external processor, and transmitting the data to another peripheral.

The reception is done via uart_event_handle which is forwarding the data arrays to ble_nus_c_string_send

Since my circuit is part of a system (i.e. ext processor), I cannot use debugger and I cannot see the errors if exist.

I will have to try "fixing" the code and check it on my system to see if it helps.

I would appreciate any ideas

RE: Problems with UART in 52840

Jørgen Holmefjord — Wed, 02 Dec 2020 19:48:33 GMT

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

RE: Problems with UART in 52840

Avi — Wed, 02 Dec 2020 17:35:16 GMT

I solved the problem by adding a delay of 4msec after each packet of 10bytes at 38K UART.