NRF_SERIAL_EVENT_DRV_ERR on initialization

[Randy Lee]

Using SDK15.3 on 52840.  I've got a UART set up talking to something at 9600 baud..

The short course here is that imediately after init, I get an IRQ with a NRF_SERIAL_EVENT_DRV_ERR.  I can send things on the UART but it's not seeing things coming in.

Setup of the UART is:

NRF_SERIAL_DRV_UART_CONFIG_DEF(m_uart0_drv_config,
                     RX_PIN, TX_PIN,
                      NRF_UART_PSEL_DISCONNECTED, NRF_UART_PSEL_DISCONNECTED,       // no flow control pins
                      NRF_UART_HWFC_DISABLED, NRF_UART_PARITY_EXCLUDED,
                      NRF_UART_BAUDRATE_9600,
                      UART_DEFAULT_CONFIG_IRQ_PRIORITY);

#define SERIAL_FIFO_TX_SIZE 32
#define SERIAL_FIFO_RX_SIZE 32

NRF_SERIAL_QUEUES_DEF(serial_queues, SERIAL_FIFO_TX_SIZE, SERIAL_FIFO_RX_SIZE);

#define SERIAL_BUFF_TX_SIZE 1
#define SERIAL_BUFF_RX_SIZE 20                // this is plenty slow so let's make this not huge anyway

NRF_SERIAL_BUFFERS_DEF(serial_buffs, SERIAL_BUFF_TX_SIZE, SERIAL_BUFF_RX_SIZE);
//
// we're going to run this thing in IRQ mode and deal with it from there.  This is slow
NRF_SERIAL_CONFIG_DEF(serial_config, NRF_SERIAL_MODE_IRQ,
                      &serial_queues, &serial_buffs, Xbee_ISR_Interrupt, NULL);


NRF_SERIAL_UART_DEF(serial_uart, 0);

Call to Init is:

    ret = nrf_serial_init(&serial_uart, &m_uart0_drv_config, &serial_config);

which is returning 0...

Right after this I get an IRQ with that NRF_SERIAL_EVENT_DRV_ERR.  After this I can send out (correctly) stuff on the TX pin (correct baud rates and everything) but it's completely missing anything on the that is coming back in.  I get no IRQs on it at all.

Any hints at what to look for here?

[Jared]

Hi there,

How does the call stack look like when the program enters the nrfx driver? Yes, I'm also suspecting that this might be caused by a break error, but I'm not entirely sure why it stops receiving data.

Randy Lee said:

The thing I'm attempting to implement here is a very simple UART problem: Sending out bytes and asnyc getting bytes back (I never know when they are coming back). The async thing is just ISR driven so I assemble information as it comes back and then dispatch other threads to be acting on the buffer.  Is there some simple way to do this or is that this library?

The serial library was deprecated in newer SDK, instead we prioritized to work on the more stable libUARTE module which has several features that overlaps with the serial interface. A feature of the module is the async UARTE: 

• nrf_libuarte_async – a library suitable for receiving and transmitting asynchronous packets. It manages the receive buffers and implements the receiver inactivity timeout. The library is using nrf_libuarte. It is meant to be used in a typical UART use case, in which the counterparty is asynchronously sending packets of variable length. In such case, user gets an event on packet boundary (that is, on timeout) and whenever the DMA buffer is full.

Which I think is what you're looking for. But it requires you to use our newest SDK. We also have a libUARTE example which should help you get started with the module.

regards

Jared 

[Randy Lee]

I might be missing something here on how to use the serial library.  On other parts, I'm used to the UART RX being active and generating an ISR when there is something in the [hardware] FIFO which I can just grab and keep for myself somewhere when it happens.  The FRAMING and BREAK errs I expect here and can safely ignore them. Not a problem.

So you're mentioning timeouts and things which has me thinking: timeouts from what? I've not asked the thing to go read anything, I'm assuming that the RX is always on and waiting and that it'll give me a ISR when there is something there to look at.  Is this how that (or a deeper layer) works or do I have to tell it to go read something explicitly?

libUARTE sound like it might work, if serious overkill (and contrary to MISRA rules) but moving to an uplevel SDK (I'm at 15.3) at this point probably isn't available to me given my timeframe to work in.  I tried that a few months ago and it's not an easy port so I don't think I've got the time to attempt it on this project.

I can also drop upper layers here and implement using lower layer stuff but I'm not entirely clear on Nordic layering here to know which layers to strip off.  What is the layer stack here and which can I go back to.  I really don't need most of the functionality and run buffer (in and out) management in an ISR easily.

Simple is better but simple is increasingly hard to come by (witness Zephyr). This would be easy on a old fashioned UART hardware implementation.

I'll check stack.  I don't think I'm overrunning it but easy enough to experiment.

[Randy Lee]

I appear to have gotten what I need by using the app_uart_xxx API stuff... That looks like it does the trick and is somewhat simpler to deal with for my (slow) application.

Thanx for the kibitz here.