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.
Sorry on the delay in getting back to you, other projects took priority for a bit.
Could I just disable USBD? I don't need the virtual COM over USB for this application. Alternately, if I could get it to work with only the virtual COM that would be acceptable as well, but I will need a UART on the board to talk to an NMEA GNSS module.
Looks like nrf_usbd_disable should disable it, but doesn't change the issue.
Could you provide an example for UART with EasyDMA? I spent a day or so trying to get that working, but didn't manage to make it compile.
I have a partially working uarte example now, it can print, but nrfx_uarte_rx_ready always returns false.I stripped out all of the legacy layer that I could, and spent quite some time fighting with what turned out to be integration/nrfx/legacy/apply_old_config.h which will redefine things like NRFX_UARTE_ENABLED unless the legacy UART stuff is also enabled.main.c: http://ix.io/1iWlsdk_config.h: http://ix.io/1iWm
You should be able to build the sdk15\examples\peripheral\uart example with UARTE enabled by setting NRFX_URTE0_ENABLED = 1 in sdk_config.h If not there is most likely something wrong in your build configuration.
So the examples\peripheral\uart actually works fine with or without NRFX_URTE0_ENABLED. I can copy chunks of text in as fast as I like.
The issue is that I'm trying to get both uarts to work, as per instructions here: https://devzone.nordicsemi.com/f/nordic-q-a/25173/nrf52840-uart1-not-working-in-sdk-14/99170#99170
Using the serial example was the most simple reproduction of an issue I was having using that.
It looks like I can't use the uart module for that as it only supports one.
You need to use the UART driver directly and not the app_uart library