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.

[Victor Nascimento]

But then, how did I run my code, with the SoftDevice (notifications enabled, transmitting at 1kbps to the Android), for about two months (since we got the DK) without any error? Can't possibly be just luck.

[Victor Nascimento]

Please note I always used the same connection time and interval. It's the same project and it was working yesterday. How this error simply poped up? Faulty DK?

[RK]

Faulty DK, no that's about the last thing I would think is likely. 115200baud is one byte every 70us. The UART has space for 6 bytes, so that's 420us worth of data. That means if data is streaming in at that rate you have to service it at least every 420us and remove all 6 bytes or it will overrun.

Those timings are much shorter than the stated timings for which the softdevice can block thread mode code. Advertising it can block up to 1700us, in connection 1180 to nearly 6000us. One single time interval of more than 420us and without flow control you overrun.

I can't say why it worked before. Perhaps your advertisements were shorter, perhaps you were sending less data, perhaps you were just ucky in your testing. The point is, with the documented times the softdevice blocks thread mode code, you cannot reliably run anywhere near 115200 baud without flow control

[Victor Nascimento]

I understand. The weird thing is: In my simulation, I send chunks of 200 bytes every second at 115200 baud. I've got the simulation running for a whole day without packet loss, with the phone connected and receiving data. Yesterday, it just started to appear for some reason. What could possibly cause this (else than processor blocking time)? I even tried disabling the advertising... the error persists. Is the CPU being blocked by something else perhaps?

[RK]

Nothing else is likely to cause it - you're doing something which is guaranteed to break. Perhaps you made one small change somewhere which altered the connection interval or some other thing just enough to ruin a lucky rhythm you had going. If your transmissions kept exactly missing radio events and got into a pattern before, it might have worked for a while, but BTLE is random enough it will always break at some point.

This is why flow control exists. Your easiest answer is to use it, then it will work, all the time, every time, no matter what, and almost every UART implementation supports it. Your other option is to look into the multiprotocol timeslot api and request slots to send your data. 15ms would be enough for one packet. You will get them when the softdevice chooses to give them to you, but you will get them, that may be enough.