If I put too many characters into a serial using IRQ mode, it stops reading input.
I haven't tried polling or DMA yet.
I can't get the onboard USB serial to work with flow control enabled(works with it disabled), so I'm doing testing with an FTDI breakout.
The serial example works consistently and correctly if I just type characters on the keyboard, but if I paste a chunk of text larger than 47 characters, the serial port reads between 20 and 40 characters, and then stops reading.
If I connect a gps unit that emits NMEA sentences, it will read some of them, and then stop reading. ~47 characters every second, and it was getting like 3-10 seconds.
Looking at what it does with gdb (I have not yet followed too closely) it seems that nrf_serial_read function just returns nothing, and everything else keeps working.
It does this with and without the hardware flow control.
I tried increasing the buffer size, but it didn't seem to change the issue.
If I change the timeout parameter on nrf_serial_read to 0 (as documentation says it really should be in IRQ contexts), it actually reads less characters when you paste data.
Am I using the example wrong, or is this a bug?
I'm a bit confused, are you using a virtual COM port over USB or the actual UART peripheral, or both?
So from what I know, if you use RX_PIN_NUMBER, TX_PIN_NUMBER, you can use either the pins or the virual COM port over USB.
With NRF_UART_HWFC_ENABLED, it doesn't work with the virtual com port, with NRF_UART_HWFC_DISABLED, the virutal com port works.
I did the above testing with NRF_UART_HWFC_ENABLED, and UART over the actual pins.
I think you might have a conflict with the USBD driver who disables interrupts for short periods of times before a transfer. If this is the case then you need to use UART with EasyDMA in order to be able to R/W via UART in a period of time that wont get "interrupted" by the USBD driver. Once the DMA buffers are loaded then you can process process the content whenever the CPU is available.