UARTE STOPRX on exact byte

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Fri, 13 May 2016 11:13:39 GMT

Sorry we are not supposed to talk about internal registers here as they are not tested with production quality. Sorry for my previous remarks. I have edited (deleted part of it) one comment.

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Fri, 13 May 2016 10:14:03 GMT

I also feel that the documentation regarding how EasyDMA moves the bytes from FIFO to buffer could be updated. I will put this forward to the designers.

RE: UARTE STOPRX on exact byte

RK — Fri, 13 May 2016 08:50:32 GMT

Aha - so my deduction/guesswork about how the UARTE treated DMA turned out to be about right. It does kind of makes sense, the UART itself just gets bytes and puts them in a FIFO and sets control lines, EasyDMA reads the lines to know when there's a byte, takes the byte and stuffs it in memory, two independent processes. So it's not that surprising that when you force stop it with the buffer not full, the EasyDMA just keeps on doing its thing. Only when you stop because the buffer is full will you then queue up bytes in the FIFO.

One piece of good which could come out of this perhaps .. some updates to the UARTE documentation to expand and clarify some of this. A casual read of the current docs leads you think STOPRX would do what the OP expected, an in-depth read leaves you scratching your head about possible edge cases.

RE: UARTE STOPRX on exact byte

parco — Fri, 13 May 2016 08:48:55 GMT

Aryan, I sent a direct message, thanks.

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Fri, 13 May 2016 08:32:24 GMT

Hi,

I have now contacted the engineer. This is not good news, the EasyDMA will continue to put bytes from FIFO to the buffer between STOPRX task and ENDRX event. The engineer's point was that when you have set the RXD.MAXCNT to 'x' bytes then the UARTE architecture assumed that you expect x bytes to come and moving bytes from FIFO between STOPRX and ENDRX should not matter. But I see that in your case this does not help. Can you open a portal page so that I can give you more information regarding using this and a possible workaround for your case.

RE: UARTE STOPRX on exact byte

parco — Thu, 12 May 2016 15:59:17 GMT

Exactly, I really don't mind the delay, its the fact that bytes received after a STOPRX are also being put in the same buffer, when I feel they should either stay in the FIFO or be put in the second buffer that I switched to in RXSTARTED.

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Thu, 12 May 2016 13:00:37 GMT

I will contact the engineer now. I have to do that tomorrow. Will update this thread later.

RE: UARTE STOPRX on exact byte

RK — Thu, 12 May 2016 12:55:55 GMT

ok that's what I'd expect to happen - however reading the original query and all the follow ups, it seems that all 4 bytes end up in the data buffer. or perhaps I've misunderstood what the OP was saying. I would expect that if the EasyDMA transaction is stopped, the very most that would get transferred would be any byte currently being transferred if there is one. That's especially true given this application is just going at 9600 baud.

He definitely says 'more bytes are being put in the buffer', so that sounds like more than one. I got the impression the manual talking about flushing the RX FIFO was in the case the transaction stopped because the data buffer was full, in which case they have nowhere else to go.

I dunno - I haven't tested it - I'm just going on what I read and my interpretation of it.

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Thu, 12 May 2016 12:54:17 GMT

I think the confusion here is that the delay between STOPRX and ENDRX event is because of the 4 bytes reception ability !!?? which I think is not correct. The ability to receive 4 bytes after STOPRX has nothing to do with the delay for ENDRX. As you said, the incoming bytes after STOPRX should stay in FIFO and I think that is how it will be. Otherwise FLUSHRX task would not make any sense to me. Do you agree?

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Thu, 12 May 2016 12:50:41 GMT

Hi RK,

You made me read the PS again :)
This is what I am certain is happening.

STOPRX is triggered, at this point we separate two things. EasyDMA and RX FIFO.

1.a) EasyDma sees the STOPRX immediately and it would try to finish any ongoing transfers from FIFO to RAM buffer. This might be delayed because of the traffic in the system bus. After finishing the ongoing transfer the ENDRX event will be given. The EasyDMA will not pick any new bytes from the RXFIFO. The delay between STOPRX and END event is directly related to the time needed for EasyDMA to finish its ongoing transfer.

1.b) the RX FIFO will still be able to receive 4 bytes of data after STOPRX is generated and this is not dependent on when ENDRX is generated. It is only depending on how many bytes are coming within next 4 byte transfer time with the set baudrate and how much space is left in RX FIFO. The incoming bytes AFTER STOPRX is triggered should stay in FIFO. You need to trigger FLUSHRX explicitly for moving this to RAM ....

RE: UARTE STOPRX on exact byte

RK — Thu, 12 May 2016 11:18:50 GMT

... in the RX FIFO ready for the next transfer. That would make STOPRX really mean stop RX.

But it seems that's not how it works in this implementation. STOPRX begins the 'waiting to stop' period, the UART will continue to receive until either 1) it detects a long period of inactivity (the timeout) and infers the sender has stopped or 2) it receives 4 more bytes. Of those bytes, as many as will fit in the buffer will go there, all 4 in many cases, the rest will then sit in the RX FIFO.

This is my mental model for what it's doing. I'd prefer it did something slightly different, but I can see reasons why it might work that way, DMA transfers run sort of independently so they aren't necessarily easy to stop. Doesn't help the original poster's use case, I think using legacy mode would do what he actually needs to get done.

RE: UARTE STOPRX on exact byte

RK — Thu, 12 May 2016 11:11:50 GMT

... work out when it's stopped sending, however it also seems still to have the 4 byte limit. That would make sense to me if, after sending STOPRX the UART stopped putting characters in the data buffer and started buffering them in the RX FIFO, immediately. That, to my mind, is what I'd expect it to do. Then the 4 bytes make sense as it only has 4 bytes of FIFO.

What it seems to do however is KEEP moving received characters to the data buffer, even though you asked it to please stop. At that point it doesn't really have a 4 byte limit, it could keep going until the data buffer is full + 4 more bytes, but it still stops after 4. I can see why, it separates the RX part into the FIFO from the EasyDMA part out of it again. To my mind it would be more consistent if the STOPRX task immediately stopped the DMA and no more bytes went to the data buffer, and any new arrivals stayed ...

RE: UARTE STOPRX on exact byte

RK — Thu, 12 May 2016 11:01:30 GMT

It is pretty confusing and the docs on this aren't the very best. Let's try another way of looking at it, I thought about it a bit just now.

Once you start a receive the UART will continue to receive until the sender stops sending. The only exception is if the UART runs out of space, when it has no choice but to stop.

Since UART is async, you never know the other side has stopped, so it infers it when there is no activity for a time dependent on the baudrate. If that time passes, it assumes the sender has stopped.

The RX FIFO is 4 bytes long, so in the usual case where you have received MAXCNT bytes and your data buffer is full, it can only receive 4 more bytes at which point, even if the sender is still sending, it has to stop.

This is where the STOPRX case, to me, seems inconsistent. It's still continues to receive while the other end send and it still uses the timeout to ...

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Thu, 12 May 2016 09:45:19 GMT

In the first paragraph I was saying about Receive TimeOut RXTO, In the second paragraph, I said that UARTE cannot stop in the midst of receiving a byte, the first paragraph and the second paragraph are saying two different things. The manual actually seems to concentrate on flow control, it did not say anything what happens when you are not using flow control. I tried to mention that even without flow control, the RXTO is still there, so you will see that delay. The manual DID NOT conflict with the behavior you are seeing, its just that it did not mention the non flow control part explicitly.

@RK, do you agree to what I say? seems like my wordings are still confusing for parco, could you put it in better words?

RE: UARTE STOPRX on exact byte

parco — Thu, 12 May 2016 08:26:41 GMT

Aryan, I'm a bit confused. In the first paragraph you say the UARTE will wait and receive up to 4 bytes to the buffer after a STOPRX. But in the second paragraph you say it will stop once it receives that byte completely. What's actually happening during testing is the first scenario with 4 bytes, and the manual figure 95 shows what you describe in second paragraph. I'm just a bit frustrated since it is deceiving.

RE: UARTE STOPRX on exact byte

Susheel Nuguru — Thu, 12 May 2016 07:41:34 GMT

Hi,

The manual was written with flow control in mind and I see that the interpretation for the non flow control part is not clear. When the flow control is not enabled, the 4 bytes waiting timeout is still enabled allowing the UARTE to receive 4 bytes. The text that says that the "bytes has to be in succession" is little confusing and I think it should have said that "UARTE will be able to receive upto 4 bytes after STOPRX has been triggered (which is equal to RXTO, still enabled when flow control is not enabled)".

parco, Are you expecting that when you trigger STOPRX you will get ENDRX event immediately? This will not happen even if RXTO is disabled when flow control is not used. This is because when you trigger STOPRX, UARTE could be in the middle of receiving a byte and it will not stop until it receives that byte completely, so according to your protocol you will receive that extra byte anyways. so instead of 7 bytes you might have 8 bytes in your buffer depending on when you triggered STOPRX.

RE: UARTE STOPRX on exact byte

esja — Tue, 10 May 2016 17:59:48 GMT

Ah, I see. Then I did misunderstand somewhat :)

And the external UART gives you no time to process after signalling package end by the 1.5ms idle time? I.e. you need to be able to receive next message immediately?

Seems like you could have used the RXDRDY event from the legacy UART to count bytes received after STOPRX and use that in the kind of suggestion RK made above. Have you tried checking that out if that still does anything?

RE: UARTE STOPRX on exact byte

parco — Tue, 10 May 2016 17:45:43 GMT

I only know to STOPRX when I see that an idle time of 1.5ms occurs. There is unfortunately no way of anticipating when that might be beforehand.

RE: UARTE STOPRX on exact byte

esja — Tue, 10 May 2016 17:43:35 GMT

But you know when to trigger STOPRX from the CPU? i.e. even if it varies between the messages? The main point was to trigger STOPRX "the time it takes to transfer 4 bytes" earlier than you currently do it to be sure that all bytes in the current RX buffer was from the same message.

RE: UARTE STOPRX on exact byte

parco — Tue, 10 May 2016 17:37:42 GMT

Thanks for the writeup. It's unfortunate the option to "close RX" is not available in hardware, I feel as though the FLUSHRX task should have that functionality, but it doesn't.

I'm not sure what TIMESLOT would be equal to. Since the messages are variable length, the time each will take is also variable.

RE: UARTE STOPRX on exact byte

esja — Tue, 10 May 2016 17:22:01 GMT

Hi,

First off, I think RK has made some great insights here, so thanks!

I can tell you that the RXTO is generated via an internal timer which is counting on the baud rate clock. Thus, if you have ample room in your RX buffer, following a STOPRX, it will take the time it takes for 4 bytes to transfer (even if no byte is transferring) for the ENDRX to be generated (followed by the RXTO). If you only have room for say 2 more bytes at STOPRX, then if the external uart is transferring continuously you would get ENDRX after those 2 bytes, and RXTO after 4 bytes, and 2 bytes would be left in the FIFO for you to push.

It could have been designed to have this feature optional, i.e. that you could make it close the RX buffer immediately or after any byte that was currently in progress, and then generate ENDRX. This is not the case in the hardware on nrf52 though.

I gather you want the protocol to not relate to a fixed number of bytes received, but rather a fixed timing of each message with a variable amount of bytes received? You just want a clean split on each of the messages? Perhaps there is an alternative (albeit a bit cumbersome) approach you can try. If I’ve misunderstood I suppose you can disregard the rest.

Use a TIMER on the nrf52-side: start the timer on RXSTARTED, give a compare event on TIMESLOT-(4*Baudrate), stop the UARTE based on the compare event.

If you keep MAXRX larger than the absolute max bytes you can receive on that baud rate in the timeslot of your protocol, you know that all the bytes in the buffer at ENDRX were transferred as part of a single message. Then do a restart on RXTO and the new RXPTR will be in effect, a new RESTARTED will restart the TIMER etc. The period your UARTE is unable to receive would be basically zero.

RE: UARTE STOPRX on exact byte

parco — Tue, 10 May 2016 14:53:47 GMT

That would most likely work, but then I would be back at firing interrupts every byte in order to switch buffers. The point of this is to avoid interrupting the softdevice.

I was thinking of never stopping the UARTE and just reading the bytes from the pointer during a Timer interrupt. The problem with that is knowing how many bytes to read, as the AMNT register is not available until after an ENDRX event.

RE: UARTE STOPRX on exact byte

RK — Tue, 10 May 2016 14:51:31 GMT

As I said, there are some thing which need clarification, and that's one of them. However I think that delay is just the uart waiting for another character, they don't have to be entirely back-to-back, there is a timeout. So you've started a transfer asking for n bytes and it's doing its best to fulfil that.

I think your use case, now you've described it, is something you just can't really do like this, stopping it at a random time and hoping to get the exact number of bytes left in the buffer. I wondered about setting the byte count to '1' and updating the pointer every byte, that might make it stop instantly after the STOP task as it has nothing else to do, not sure that would work either however.

RE: UARTE STOPRX on exact byte

parco — Tue, 10 May 2016 14:37:32 GMT

I do not know how many bytes will be in a message beforehand, that is decided by that small finite idle time of 1.5ms. So I end up with 11 bytes read in my buffer but I have no idea where in those 11 bytes the STOPRX was actually triggered.

Again, you mention (along with the manual) that it will continue to receive up to 4 bytes after a STOPRX as long as they are sent immediately after and in succession. Yet you can see from the oscilloscope capture the last STOPRX task is triggered after the last byte, but it's still taking a 4 bytes delay.

RE: UARTE STOPRX on exact byte

RK — Tue, 10 May 2016 14:36:45 GMT

.. in that way you get your individual buffers, you just manipulate a couple of bytes and the count between stopping one transfer and starting the next.

However quickly the UART stopped, I think you were always going to have at least an occasional extra byte in the buffer just owing to not quite stopping the task before the next character had started coming in. So this was always a case you were likely to have to deal with in code. But coding using the actual number of characters you actually received is pretty simple and saves you from all the vagaries of how fast something stops and whether you got to the stop event in time.