nrf52840 serial

[mtfurlan_t]

If I put too many characters into a serial using IRQ mode, it stops reading input.

I haven't tried polling or DMA yet.

Using

• nRF5_SDK_15.0.0_a53641a
• gcc-arm-none-eabi 6.3.1 and I also tried segger
• nRF52840-DK with a PCA10056 1.0.0
• examples/peripheral/serial.

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.

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.0.0/group__nrf__serial.html#details

Am I using the example wrong, or is this a bug?

[haakonsh]

I'm a bit confused, are you using a virtual COM port over USB or the actual UART peripheral, or both?

[mtfurlan_t]

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.

[mtfurlan_t]

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/1iWl
sdk_config.h: http://ix.io/1iWm

[haakonsh]

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. 

 

[mtfurlan_t]

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.

[haakonsh]

You need to use the UART driver directly and not the app_uart library

[mtfurlan_t]

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

[haakonsh]

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.

[mtfurlan_t]

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?

[haakonsh]

"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. 

[mtfurlan_t]

My apologies, I saw the error of "no member named 'use_easy_dma'", and checked the documentation, where it is not listed: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.1.0%2Fstructnrf__drv__uart__config__t.html&resultof=%22%6e%72%66%5f%64%72%76%5f%75%61%72%74%5f%63%6f%6e%66%69%67%5f%74%22%20

That should be linking to the page for nrf_drv_uart_config_t in sdk 15.1.0

Documentation is actually the same for 15.0.0.

In nrf_drv_uart.h, we need the following to be true to have use_easy_dma:

defined(NRF_DRV_UART_WITH_UARTE) && defined(NRF_DRV_UART_WITH_UART)

Those are defined in the same file, if UARTE_PRESENT and NRFX_UARTE_ENABLED or NRFX_UART_ENABLED are set respectively.

Both of those are in the sdk_config.h, but both are actually overridden by /integration/nrfx/legacy/apply_old_config.h

In the end I had to enable UART_LEGACY_SUPPORT. in sdk_config.h

If you want I can test if it was actually a change in the SDK that made that necessary or if it was an accident on my end.

Either way, now that that is fixed, input still doesn't work.

main.c: http://ix.io/1m0J

sdk_config.h: http://ix.io/1m0K

[haakonsh]

I need you to read out the content of the UARTE[0] and [1]'s registers before your first transmission.