I am using nrf starter kit and nRF51822 DK modules atached. I'm using external usb-com uart modules (based on FT232 chips) for communication with PC (Win7) and hyper terminal clients for data send/receive. Currently I'm experimenting with modified gazell example project to include data received from uart and to transfer between modules as in com cable replacement setup. If I connect usb-com modules directly with each other (thus error free communication) and set baudrate 921600bps, I can transfer data at aproximately 890kpbs transfer rate (using zmodem file transfer). Now i'm trying to include radio transfer in data path. Uart is configured with hardware flow control, uart module on nrf51 is configured on high priority with extended buffering (fifo like size of 1kB) and aditional checking for receive buffer usage to stop and start RX transfers. Uart Error interrupt is enabled and i'm getting several errors representing Buffer overflow during large data chunk receive (3-15kB in size). I'm guessing that hardware flow control is not quick enough to prevent RX register overwriting. Another issue is stopping RX transfer without data loss. I'm thinking that it could be possible to use aditional I/O for RTS/CTS manual control together with uart hardware to pause Rx transfers correctly. What solutions could be usable to correct flow control not lowering baudrate? as this is the basis of transportation layer for later tasks.
Beware that there is a bug in the nrf51_bitfields.h file, in that the value for 921600 baud rate is incorrect. It should therefore not be used, and if you do, the actual baud rate might be different from…
The latest app_uart_fifo file (included in the SDK 9) contains a bug. 3 bytes where systematically lost (even with HFC) because of a bug in the UART0_IRQHandler function.
Be sure that the in the UART…
I have tested your fix and it worked for me too. I have to include this in the known bugs of SDK 9.0
Beware that there is a bug in the nrf51_bitfields.h file, in that the value for 921600 baud rate is incorrect. It should therefore not be used, and if you do, the actual baud rate might be different from expected. See this question for information on baud rate calculation. Does using a somewhat different baud rate help on this problem?
If not, this could also be due to the peer device not reacting quick enough when RTS is deasserted, and by that overflowing the buffer. This is a problem that I believe has been seen internally. The upcoming, new chip revision therefore features a six-byte buffer to alleviate this. It could therefore also be worth it to try getting hold of this revision and test whether you see different behavior. Please contact the sales manager for your area for more information on this. If you don't have his contact information, please send me a private message with your location.