UARTE Frame error receiving

[Thomas]

Hi

I am seing framing errors when receiving using UARTE.

It is not external hardware, I have checked with different other interfaces and measured timing, no problems there.

BUT, doing the same with UART instead of UARTE I do not get any framing errors (same hardware setup).

Actually with UARTE I only get one rx character then framing errors....

[Einar Thorsrud]

Hi,

Yes, SD 16 is only API compatible with version 7 SoftDevices (see SDKs and SoftDevices compatibility matrix).

[Thomas]

Fixed the device family pack thing, but a little bit messy as version 8.27 is not available so I can download 8.28 and then the example project still has error and complains, so the pack selection has to be fixed in the setup….

I will see if I can get it running with 15.3 to begin with.

[Einar Thorsrud]

Hi,

You can specify 8.28 in the Keil project though Under "Manage runtime environment", and changing the options of the Device in the project tree. But it is a bit of a hassle. SDK 15.3 should be just fine, though libuarte is improved in SDK 16 (first time out of experimental).

[Thomas]

I will try to copy the version from SDK 16 to SDK 15.3 and see if I succeed.

[Thomas]

I'm getting a problem with setup (maybe timer) when initialising the first uart.

I have defined the following.

NRF_LIBUARTE_ASYNC_DEFINE(libuarte0, 0, 0, 0, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);
NRF_LIBUARTE_ASYNC_DEFINE(libuarte1, 1, 1, 1, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

With libuart1 it is OK and my code can run, if Im instead using libuart0 the application crashes with a SOFTDEVICE: INVALID MEMORY ACCESS.

My configuration is like this:

nrf_libuarte_async_config_t nrf_libuarte_async_config = {
.tx_pin = id == 0 ? TX1_PIN_NUMBER : TX2_PIN_NUMBER,
.rx_pin = id == 0 ? RX1_PIN_NUMBER : RX2_PIN_NUMBER,
.baudrate = baudrate,
.parity = parity,
.hwfc = NRF_UARTE_HWFC_DISABLED,
.timeout_us = 4000,
.int_prio =APP_IRQ_PRIORITY_LOW_MID
};

Inside nrf_libuarte_async_init() the application jumps to the app_error_fault_handler with id 0x00001001.

It is a little difficult to see exactly what happens. As stepping througth the initialization changes the position of where it happens. (some background interrupt maybe).