ERRORSRC 0x1 on UART handler

[Victor Nascimento]

Hello,

On my custom board, I'm receiving chunks of UART data, without flow control, at 115200bps. Sometimes (its quite frequent now... sometimes after 10 chunks, sometimes after 100 chunks), im getting ERRORSRC 1 on APP_ERROR_HANDLER(p_event->data.error_communication); line.

My board doesn't include a 32kHz oscillator, and Im using NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION as my clock source (I don't care about current consumption). I'm also using SDK 8 with SoftDevice 8.0.0.

What would cause this? Any idea how to solve it?

edit Edited title so it makes more clear. Thanks @RK

[RK]

No you're not getting that error. That field in the event structure doesn't return an NRF_ERROR_* code (look in the documentation or just read the code), it returns the raw error from ERRORSRC in the UART.

If you then look at the nRF52 series documentation for ERRORSRC you'll see '1', which is the error code you're getting, is an overrun error, which, since you're trying to do no-flow-control at 115,200 is not very surprising.

You can probably run at that baud rate without flow control if the chip's not doing anything else, I'm going to guess you're trying it whilst using the softdevice and that's not going to work.

[RK]

Oh dear - what's on the other end which doesn't even have flow control? I was anticipating that you had SOME control over the other device, if not flow control then at least you write it a byte and say 'send now' and it sends up to 100 bytes or 200 bytes or whatever, then it waits for you to ask it again, or you can signal it on a GPIO once to get it to send a chunk of data. If you have no control over it at all and it can send at any point then, no, the timeslot API won't help you either. If it sends when the radio is working, it'll fill the buffer before you have a shot at emptying it.

So you're left with remarkably few choices. The nRF52 would solve this problem because the UARTE has DMA on it, so you can point it to a chunk of memory and it can write there, you just read it in when you have time.

No good solution. Add another UART chip with a buffer, or send very slowly.