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
This question has become "How do I use the NRFX UARTE driver to read input?"
In the code I posted, I'm already the NRFX UARTE driver directly, but it can only print and not read.
I changed the code I had to use both UARTs, and it can print to both without the modification from Jakub Rzeszutko in the linked post, but I still can't read from the UARTs.
It does not suffer from the issue of choking on data bursts.
main.c printing to two UARTs: http://ix.io/1jIS
you need to pass a couple of event handlers to the nrfx_uarte_init functions, or all rx/tx calls will be blocking.
You also need to catch and check the return codes of your driver calls.
I was trying to use blocking rx/tx calls.
I switched to using the event handler, and it never gets an event of type NRFX_UARTE_EVT_RX_DONE or NRFX_UARTE_EVT_RX_DONE
I was already calling APP_ERROR on the return codes of the driver calls, and that will block if it's not a success. The code doesn't block, so they're all returning NRF_SUCCESS.
Newest code: http://ix.io/1lZh
Also I updated to nRF5_SDK_15.1.0_a8c0c4d
There is a bug where "use_easy_dma" which was removed from "nrf_drv_uart_config_t", is still used by "components/libraries/serial/nrf_serial.c" line 208
I just commented it out, is that the suggested fix?
"There is a bug where "use_easy_dma" which was removed from "nrf_drv_uart_config_t", is still used by "components/libraries/serial/nrf_serial.c" line 208"- use_easy_dma is still a member of nrf_drv_uart_config_t. See line 192 of \integration\nrfx\legacy\nrf_drv_uart.h.You need to set the necessary defines in sdk_config.h or the preprocessor will not let the compiler use it.