UART Maximum FIFO Size

[Diogo]

Hi all,

I have to transfer a lot of data over the UART channel, and run into some problems...

First problem was/is the UART FIFO Size. There are three different defines on the SDK for the RX/TX buffers:

#define 	TX_BUF_SIZE   600u
#define 	RX_BUF_SIZE   TX_BUF_SIZE
#define 	RX_BUF_QUEUE_SIZE   4u
#define 	TX_BUF_SIZE   4u
#define 	RX_BUF_SIZE   32u
#define 	RX_BUF_QUEUE_SIZE   8u
#define 	TX_BUF_SIZE   32u 
#define 	RX_BUF_SIZE   600u
#define 	RX_BUF_QUEUE_SIZE   2u

My block is 512bytes long in data plus 3bytes of header and 1byte of checksum. My first attemp was to use 520bytes of buffer, which resulted in unpredictable behaviour from the NRF51822. Further reading on the documentation, I then realised that the size has to be a power of 2... So how can one expect a reliable behaviour of using 600 bytes (from the builtin defines of the SDK's). If my math is not that bad, there is no power of 2 that gives 600... Unless the exponent part can be decimal (???)...

I now run my fifo with a 1024byte size (from which I'll be only using the 516 bytes above), and it seems to be working... At least my data seems to be travelling ok to the end-point. What is the maximum value of the fifo size one can use? Can I expect reliability from my device while using this 1024 fifo? Again I will be transferring 516 bytes (I have implemented software hand-shake to get more data only once the previous packet as been successfully sent).

Using sizes different from a power of 2 resulted in different behaviour depending on the size of the buffer and the board (tested it across several boards).

From what I can see, there are a lot of UART related problems throughout the forum, when the fifo size starts growing, which I recon can be related to this problem.

Last I can provide some other info about my setup (which I think don't really interfere with this behaviour): SDK 8.1.1 SD130 v1.0.0 NRF51822XXAC REV3

Thanks in advance, Diogo

[Paul]

Do you have stack overflow tracking enabled in your software? The first thing I would do is to make sure there is no stack overflowing happening.

[Paul]

Also please provide a little more details about the "different unpredictable behaviour". It will ring many bells from the developers in the forum. :-)

[Diogo]

No there is no stack overflowing... And by unpredictable behaviour I meant: there was missing data on the packet; and/or incorrect data (tried to print an "hardcoded" 'U') and was getting other chars... There was also a buffer/fifo size that had the uC on a continuously rebooting loop... If there isn't stack overflow on my code, and I use a power of 2 on the buffer size, can I assume there will be no problem on the UART? My main concern is that there is a maximum size on the buffer/fifo which may not be noticeable as an error now, but can cause missing/incorrect data TX...

[Diogo]

Using 1024 buffer size while transmitting less than the 600 bytes seems to be working... IMHO that 600 byte TX_BUF_SIZE define should be removed from the SDK, it can be misleading... If I recall correctly in the bootloader example that is the size used... Not sure if a fifo is used there but can also be a potential point of trouble. Not sure if I mentioned but the beginning of the packet was correct, the amount that was correct was not fixed though... Meaning sometimes 32 bytes were ok, others 49, etc...

[Paul]

First of all, we are ruling out baud rate issues, please confirm. The timing on both side is in 5% of the bit width timing. Normally I use a PC UART test tool to verify sender and receiver separately if I am struggling with this type of problem. I bought Comm Operator. Very useful tool.

If there is no hardware issues. Those continuously rebooting does sound something wrong with your stack settings. Are you using RTOS with SD130?