rak5010 uart_overflow

I am having an issue with UART_OVERFLOW errors on the RAK5010 comms with the BG96

You see at the end of the below commands the QNWINFO response from the BG96 is missing some characters. (But the issue happens in random places, not just there). If I slow the baud rate from 115200 to 19200 the problem pretty much goes away until I start using the BG96 to download a 22kb file from a server, then I get overflows again - although in this case it might be the 19200 is not fast enough to keep up.

Using the same code on a RAK8212 (which defaults to 115200) I dont get overflows (although I have not tried the file download on that)

In theory I have enabled the CTS control on the BG96 so with the commands below there should never be an overflow ? Any ideas ?

["AT+CSQ\r\n"
] "\r\n+CSQ: 19,99\r\n\r\nOK\r\n"
["AT+CEREG?\r\n"
] "\r\n+CEREG: 0,1\r\n\r\nOK\r\n"
Send to server
["AT+QHTTPCFG=\"contextid\",1\r\n"
] "\r\nOK\r\n"
["AT+QHTTPCFG=\"requestheader\",1\r\n"
] "\r\nOK\r\n"
["AT+QIACT?\r\n"
] "\r\nOK\r\n"
["AT+QICSGP=1,1,\"iot\",\"\",\"\",1\r\n"­
] "\r\nOK\r\n"
["AT+QIACT=1\r\n"
] "\r\nOK\r"
["AT+QIACT?\r\n"
] "\n\r\n+QIACT: 1,1,1,\"10.34.15.70\"\r\n\r\nOK\r\n"
["AT+QIDNSCFG=1,\"8.8.8.8\",\"8.8.4.4\"\­r\n"
] "\r\nOK\r"
Connected
["AT+QNWINFO\r\n"
New interpreter error: UART_OVERFLOW
] "NFO: \"CAT-NB1\",\"53001\",\"LTE BAND 28\",9554\r\n\r\nOK\r\n"

I am a bit stuck on this one, as I can generate the UART_OVERFLOWS with small amounts of data being sent on a 1 sec interval. And as this error is coming from the bottom layers of Espruino it is a little hard to debug.

In the meantime I am going to drop the baud rate back to 19200 and see if I can get a file transfer from BG96 to NRF working with flow control.

But I would love to get to the root of this problem

So what I found is if I reduce the baud rate to 9600 then it is stable enough for my 22kb file to download without corruption as it is transferred over the serial port. Does not seem correct though to need to go this slow on a hardware serial port ?

I used to set baudrate to 9600 Baud (maximum) for software UART, especially on NRF52 platforms. For hardware UART I thought 115200 baud was still fine, but never really tested on NRF52, because it only provides 1 HW uart and I prefer to keep it as a console interface when BLE is disconnected.
I would recommend not to go much higher than 9600 Baud on NRF52, unless flow control is implemented.

With further testing I have found that I still cant get reliable transfer of 22kb from the BG96 to NRF52840 (RAK5010).

But what does seem to help (needs more testing) is for me to pause all BLE operations ie disconnect from the IDE and also pause the BLE scans I am doing in my code.

The NRF52840 has a second serial port, so I might set that up for the IDE

But what does seem to help (needs more testing) is for me to pause all BLE operations ie disconnect from the IDE and also pause the BLE scans I am doing in my code.

I came across this article https://jimmywongiot.com/2019/12/15/high­-speed-uart-on-nordic-nrf52-series/ that describes similar issue - when using older uart mode which does not use DMA and trigger interrupt after each character sent/received it can happen that bluetooth interrupts with higher priority can cause lost characters.

They discuss much higher baudrates there, however at 115200 sending/receiving one byte should be about 87uS (10bits/115200 ?) which is still pretty short compared to latencies mentioned in that article so it can be the issue.

Current UART code in Espruino is old and shared with nrf51 so it is probably not used in UARTE mode (=with DMA). Here I see only one character is expected when receiving https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/jshardware.c#L176­3

ok, that could explain why some care needs to be taken around serial and BLE at the same time. IT is strange that my code works fine on the RAK8212 (NRF52832), so there must be something subtlety different. @Gordon would implementing UARTE mode ever be on the roadmap ?

Sorry for the delay - I missed this post...

Strange about the nRF52840/nRF52832 being different - as you noted the 532 generally works pretty reliably...

The issue has been as far as I know that when you enable UARTE mode the UART DMA hardware doesn't actually interrupt you when a byte is received - it only interrupts when the buffer you give it is full - which is the reason why the library uses 1 byte DMA buffers (which is worse than not using DMA - I did try!).

So perhaps the library mentioned in the article that @fanoush mentioned above might work - but we'd need a special library that is able to hack around the UART hardware - there is some hint of timeouts being used there, which may work but may impact power usage significantly.

Right now this is low priority for me though - nothing I sell uses higher speed hardware serial on nRF52840, and while I do provide builds (for some reason) for the RAK5010, I haven't been paid for doing so in 3 years so I'm definitely not doing free support :)