UART receive in background without callback on nRF52 SDK11

RE: UART receive in background without callback on nRF52 SDK11

Hung Bui — Mon, 18 Apr 2016 12:18:57 GMT

@maxv: Have you tried the example I made below ?

RE: UART receive in background without callback on nRF52 SDK11

maxv — Fri, 15 Apr 2016 14:02:14 GMT

@puz_md: Thanks for the update. I probably will try your idea and see how well it works. More here, if I get there.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 15 Apr 2016 13:43:32 GMT

@maxv: No real solution. You could trigger a buffer change with the STOP_RX task (in combination with the END_RX - START_RX shortcut), which should return the current buffer even if it is not full, and continue with the next buffer. But there is a small chance that, if STOP_RX is called around the same time when the buffer actually becomes full, the buffer may be switched twice, before the next buffer has been set by the interrupt handler. In this case, it might come unpredictable behavior and/or data corruption. Just hoping for some more feedback from the Nordic employees if switching the buffer without this kind of glitch is supported by the hardware.

One Idea I just had: You could configure a very large buffer and periodically trigger the STOP_RX task, just making sure that the buffer can never become full within the interval. This way, it should be pretty safe.

RE: UART receive in background without callback on nRF52 SDK11

maxv — Fri, 15 Apr 2016 13:14:13 GMT

Was there a resolution to this situation? I'm also trying to use EasyDMA + a timeout to do serial RX, but I run into the same problem that the UART event handler will not get called if the RX buffer hasn't been completely filled. i.e. partial fills don't eventually cause a timeout.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Tue, 12 Apr 2016 11:08:10 GMT

...then I think the UARTE device cannot be used for 100% reliable asynchronous (low latency) data reception the way it is currently designed :(

It would be much easier if we could just access the current state of the receive buffer (RXD.AMOUNT), but I remember somebody saying this value would ony be valid when the ENDRX event has been triggered.

RE: UART receive in background without callback on nRF52 SDK11

Hung Bui — Tue, 12 Apr 2016 10:48:48 GMT

I don't think FLUSHRX task would work when the UARTE is still active in receiving mode.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 08 Apr 2016 13:53:42 GMT

Hi Hung, that's just what I wrote in my reply 4 hours ago. I agree, it could come to glitches when ENDRX is triggered both by MAXCOUNT and STOPRX within a short intervall, without enough time to update the RX buffer in the event handler before the next ENDRX is triggered.

Maybe bat13 has some time to try your code, I'm currently pretty busy with my project, using the classic app_uart for the time being. Further, I have old nRF52-DK's that seem to be not 100% compatible with the official releases when using the timers. In my case, I wouldn't use the timer to trigger the stop task, but the function call that tries to read data, using two RX buffers that create something like a circular FIFO.

One more question about the FLUSHRX task: What happens if this task is triggert while receive operation is active? Might this task help to prevent glitches?

RE: UART receive in background without callback on nRF52 SDK11

Hung Bui — Fri, 08 Apr 2016 13:27:18 GMT

Hi,

I understand your concern about when the number of byte received doesn't reach the MAXCNT and we won't able to know how many byte we receive until we trigger a STOPRX task. And then if we trigger the task we may interrupt reception. But what if we have a SHORT to connect ENDRX with STARTRX, we can restart receive mode. It's the same when we reach MAXCNT and receive ENDRX. Note that when ENDRX-STARTR short is triggered, there will be no RXTO event (I couldn't find documentation about this, need to double check)

I implemented a small example. That I use an app timer to trigger a STOPRX task every second. I am not 100% sure there will be no glitch since there is a chance that the STOPRX task happens at the same time with the ENDRX from MAXCOUNT reached event. It could be a race condition there. A small modification in nrf_drv_uart.c added, I commented out if (amount == m_cb.rx_buffer_length) in uarte_irq_handler(). Could you try the example and let me know if it works for you? (SDK v11)

uart - EasyDMA.zip

(Posted this without reading the previous answers, I agree with puz_md and bat13 )

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 08 Apr 2016 12:17:04 GMT

if the ENDRX-STARTRX shortcut is not set, there will be no "next buffer". And if the shortcut is set, receiving will be restarted and no RXTO will be issued. A new buffer is only used at the moment the STARTRX task is triggered. But like I saif, RXTO only seems to make sense when using flow control. Without flow control, it may be used, but doesn't help very much.

RE: UART receive in background without callback on nRF52 SDK11

bat13 — Fri, 08 Apr 2016 12:03:01 GMT

I read it in the documentation. But in this case, all remaining data from the FIFO falls to the next buffet (in theory, the reception time is active). Therefore, such additional processing RXTO not needed. Maybe I'm wrong :) Another question, if happened NRF_UARTE_EVENT_ENDRX, but the data did not come, whether to switch to the next buffer will happen. I do not tested it yet.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 08 Apr 2016 11:52:22 GMT

UARTE does have a small internal RX FIFO. It can receive up to 4 bytes after the RX_STOP task has been triggered (in fact that seems to be intended for robust flow control when the communication partner sends some more bytes after RTS is released). So, if the STOPRX task is triggered, some more bytes may reach the RX circuit, and they may be received after the ENDRX event has been triggered. This is why, after receiving the last valid buffer in ENDRX, one more buffer can be used in RXTO (timeout) to read those remaining bytes into a separate buffer. If you don't use flow control, you can ignore the FLUSHRX task as you will lose data anyway (because there is no flow control that stops the sender).

The great benefit of EasyDMA is that no interrupt is issued for each byte that has been received. This can greatly improve performance, and also, it makes the UART more robust while the high priority Bluetooth code within the SoftDevice is running which may delay your UART interrupt handler for so long that data will be due to a FIFO overflow - the hardware FIFO on the classic UART is only 6 bytes. With EasyDMA, you can use much larger buffers that are also handled in background (while BT code is running).

RE: UART receive in background without callback on nRF52 SDK11

bat13 — Fri, 08 Apr 2016 11:29:19 GMT

Launched double buffer (something like cyclic DMA mode to STM32). In the interrupt indicates the beginning or middle of the buffer. NRF_UARTE_SHORT_ENDRX_STARTRX automatically starts the next buffer. Working. Sometime timeout call nrf_drv_uart_rx_abort. I fall into NRF_UARTE_EVENT_ENDRX handler. I can get a part of the buffer and switch to the next. NRF_UARTE_EVENT_RXTO in such cases do not occur. Still in doubt about the loss of data. Perhaps it is necessary to cause NRF_UARTE_TASK_FLUSHRX. But I can not understand at what point. Reception do not stop. Pooling is not very convenient. by Interrupt the flow of events would have been better.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 08 Apr 2016 09:40:28 GMT

Based on my discussion with bat13 in the comments, I have been looking into the UARTE documentation in Product Specification v1.0 and came to the following conclusion:

My current assumption is that it should be possible to prevent data loss if the START_RX task is triggered immediately after the END_RX event (see shortcut in SHORTS register). If the corresponding shortcut is set, START_RX should be triggered by END_RX again, just like when the RX buffer has become full. If you have a look at figure 95, p332, the shortcut has to be reset to really stop reception ("ENDRX_STARTRX = 0") If this bit stays 1, reception should continue.

I didn't have time yet to check if this feature is already supported by the driver already (when used in EasyDMA mode).

Race conditions also seem to become important here: A critical situation is when STOP_RX is issued shortly after the current RX buffer becomes full and triggers a END_RX task - END_RX might be triggered twice within a short time, before there was time to update the double buffered pointers... this might lead to corruption of RX data. Is there a good way to prevent this scenario? Maybe the FLUSHRX task can help?

I'm really curious about is the FLUSHRX task. According to the current Product Specification, it is only used if RX has been stopped. Maybe it can also be used during reception to switch to the next RX buffer? Although that would be pretty much the same as described above with the STOP_RX task and the shortcut. Would be nice to have some more information.

Update:

One more question to the Nordic engineers

From the moment when a full buffer is detected (which initiates a buffer update using the RX.PTR) to the moment when the RX.END interrupt handler is called, is it possible that application code which writes to the RX_STOP task is executed? And how will the STOP_RX task be handled in this case?

Clean buffer switching might work under the following conditions:

Either a buffer full condition immediately interrupts the application control flow and switches to the END_RX interrupt hander, so that calling the STOP_RX task from a lower priority than the interrupt handler is prevented
Or a STOP_RX task that is issued from the moment when a full buffer is detected to the moment the interrupt handler is called will be merged with the full buffer STOP_RX event

To the application engineers: A workaround proposal

Create a large RX buffer which cannot become full within a defined time interval, even in a worst case scenario.
Within the mentioned time interval, periodically call the STOP_RX task to switch to the next buffer. It might even be possible to use a hardware timer and the PPI to trigger the STOP_RX task.
In the END_RX event handler, configure the next buffer (double buffering) and handle the bytes received (if any).
In your timing calculations, take the timing requirements from the SoftDevice into account (it might be busy for quite some time and delay the END_RX handler, so that more data might arrive in the buffer than originally calculated).

This way, using the EasyDMA feature, it should be possible to implement robust UART reception that doesn't lose data when the SoftDevice is active (e.g. during a radio event). The old UART device only had a short FIFO buffer that would overflow on long SoftDevice activities.

The major drawback of this implementation is that it will cause periodic interrupts, even if no data has been received.

Maybe the sample posted by Hung Bui (have a look at his post) shows something similiar to this workaround. I didnt have time to try it out yet. My extra suggestion to his implementation would be to use a large RX buffer that cannot be filled within the configured time interval (+ some extra time for the SoftDevice).

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Fri, 08 Apr 2016 09:36:04 GMT

@bat13: Oh, that's bad news :( But I can't imagine that the Nordic folks would create a device that is not capable of receiving arbitrary data... maybe the product specification is not complete yet. I also had a look at the UARTE documentation and I think some parts are still missing. Hopefully, some Nordic employees will give some feedback soon...

I have looked a bit into the UARTE specification, I'm posting my current assumptions in a separate reply to this thread, hopefully it will be recognized by some Nordic employees ;)

RE: UART receive in background without callback on nRF52 SDK11

bat13 — Thu, 07 Apr 2016 18:46:55 GMT

Quickly I looked through the documentation. DMA has an automatic double buffer. But the trouble is that the access to the current counter is available only after the end of the RX. And, as I understand it, nrf_drv_uart_rx_abort give access, but will interrupt the reception. This may result in loss of data at high speeds, when Ble stack can tighten this pause. Hopefully I missed something.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Thu, 07 Apr 2016 17:48:27 GMT

@bat13: That's the idea I had myself. It would be nice if after a RX abort, if the second buffer would immediately be activated. Just try it out and give me some feedback if it works ;-) Although I fear there is a small risk that data may be lost while the EasyDMA buffers are updated by the driver (maybe they will have to trigger the STOP task, update the buffer, and trigger the START task again. And data transmitted within this interval gets lost.

I have another Idea that I would like to try out: I suppose there shuold be a register containing the current offset within the EasyDMA RX buffer. If this register is readable by software, application code can find out how many bytes have already been received in the current buffer. If you use two adjacent buffers, you could treat them as a circular FIFO and update head and tail each time a RX complete event is triggered. But you can also update the tail and read out some bytes from the active buffer before the event is triggered if you can find out the EasyDMA state. Altough you have to make sure that there are no race conditions when updating the tail (different control flows!). In short, that's what I would like to implement, If I can get some time for this.

RE: UART receive in background without callback on nRF52 SDK11

bat13 — Thu, 07 Apr 2016 17:19:05 GMT

"But if the data stream suddely stops and your buffer does not become full with the last rx byte" - That's what I meant, "if the flow is interrupted." As I understand it, periodically causing nrf_drv_uart_rx_abort can interrupt the reception NRF_UARTE_EVENT_RXTO. But what next? if automatic switching to the second buffer will happen? And you can analyze the leisurely first buffer? Where can I read more about the behavior nrf52 in this case?

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Thu, 07 Apr 2016 16:45:30 GMT

@bat13: if you want to receive continuous data, you can use nrf_drv_uart in EasyDMA mode. As far as I understand, you will get callbacks each time a complete buffer has been received (I didn't try it out yet, though).

If you want to receive continuous data, the current driver should just work fine (use the double buffering by handing over two buffers with nrf_drv_uart_rx(), and one buffer each time you get the data ready event). But if the data stream suddely stops and your buffer does not become full with the last rx byte, you might wait forever for the final data bytes.

RE: UART receive in background without callback on nRF52 SDK11

Christopher — Thu, 07 Apr 2016 16:40:39 GMT

@puz_md Our next product will be based on nRF52 of course ;)

RE: UART receive in background without callback on nRF52 SDK11

bat13 — Thu, 07 Apr 2016 16:22:52 GMT

I am also looking for an example EasyDNA+UART. Nrf51 lost data at high speeds without DMA. Moved to the DDK 52, but now can't understand how to automatically receive a portion of the data, if the flow is interrupted.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Thu, 07 Apr 2016 12:13:27 GMT

Thanks for the reply. Although, the post you mentioned doesn't give much new information. My conclusion at the moment is that it is currently not feasible to use the UART with EasyDMA in a FIFO-like scenario (receiving asynchroneous randomly sized data packets) as there is no such driver available.

I have considered implementing a driver extension on my own. But I'm a bit short on time, so maybe I'll just continue using the old app_uart_fifo without EasyDMA.

RE: UART receive in background without callback on nRF52 SDK11

puz_md — Thu, 07 Apr 2016 11:38:08 GMT

@metch: Do you already have a product that uses the nRF51? If not, why not moving to the nRF52 platform if you need efficient UART handling?

RE: UART receive in background without callback on nRF52 SDK11

Christopher — Wed, 06 Apr 2016 16:58:01 GMT

I am also looking for an example of the UART with DMA. I currently use the UART with HFC on the nRF51, but unfortunately there is no DMA with the nRF51 :(

RE: UART receive in background without callback on nRF52 SDK11

Christopher — Wed, 06 Apr 2016 16:56:34 GMT

This post contains some information about the UART peripheral and example with the nRF52. See the @hungbui 's answer.

In SDK11, two issues with the UART have been fixed:

UART: Fixed a glitch on TX pin when initializing the driver
UART: Fixed the problem that TX bytes were sent in wrong order in app_uart_fifo

The documentation about the FIFO implementation is available in the "SDK common libraries" section, see this link. The FIFO API has a new function in SDK11.