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]

Look up the radio notification API - that will tell you just before the softdevice does a transmission and again just afterwards.

[Victor Nascimento]

RK, I'm using the nRF51 DK which according to this: devzone.nordicsemi.com/.../ have the third revision of the processor. It's also said that it allows a blocking time of only 240us which would hold transfers up to 192kbps. Is that correct? What am I missing here?

nRFGo Studio reports it as QFACA10 (0x0086)

[RK]

Well have you turned it on and enabled it? Do you have other interrupts which you're servicing which are higher priority?

I can find zero documentation in the S110 docs about the guarantees when the CPU blocking mutex is disabled, only the questions here which makes it rather hard to say what exactly is guaranteed. eg you may be unblocked after a maximum of 250us but how long do you get after that before you are blocked again? I'll file a support case for better documentation.

The point remains that you're overrunning the UART receive buffer so it's not getting serviced for one reason or another.

I see another claim that with SD 8 you don't even need to set the flag manually, it's automatically set, however I still can't find a good discussoin of what's guaranteed in the release notes.

If you have a logic analyser, now is the time to get it out and start looking.

[RK]

i found all the timings in the S110 spec version 2. They take a bit of reading but all the data is there. There's times of 510us max in the lower stack for some events during connection, 440us advertising. Then there is time in the upper stack too. Which begs the question .. what priority is your UART interrupt and has that changed? If it's '1' (APP_HIGH) then there should be time to keep the UART serviced at a conservative 80-90kb/s. It certainly would help if the interrupt service code runs at APP_HIGH and only clears the UART to memory and any processing happens at a lower priority later. You can have as little as ~650 instructions between advertising events so clearing the FIFO fast is the best thing. Also check your advert interval and latency - perhaps you can connect less-often and give yourself more time.

[Victor Nascimento]

I removed all the processing from the UART handler. As my packets come in a very specific way, with delimiters and stuff, I could just setup a flag telling my FSM to process the packet when it's ready, reading from a buffer. In the end, it's working as before! Running the simulation, I'm not getting any overrun error anymore.

Thank you very much for your time, effort and hints.