Hi,
After years of working with nrf_serial, we are starting a new project and want to use the lastest and greatest SDK and get rid of legacy drivers. libuarte is tempting because of its use of DMA.
When working with libuarte, I came up with a couple of (maybe obvious) theories on its implementation for which I did not find anything in the documentation (though I might not have looked hard enough). The described behaviour has ramifications on the application implementation.
1. The TX data buffer provided to nrf_libuarte_async_tx() is used by the driver as long as data transmission is ongoing.
Experiment based on \examples\peripheral\libuarte on the PCA10056 to show the effect:
err_code = nrf_libuarte_async_tx(&libuarte, text, text_len); APP_ERROR_CHECK(err_code); memset(text, '$', 25);
Result:
UAR$$$$$$$$$$$$$$$$$$$$$$opback:
instead of:
UART example started.
Loopback:Theory: The HW DMA directly accesses the data buffer for transmission. There is no TX data buffer instantiated by libuarte.
Consequently, the application needs maintain TX buffers as long as they are in use, i.e. until the NRF_LIBUARTE_ASYNC_EVT_TX_DONE has been detected.
BTW, it would be nice to be able to query the libuarte state instead of deriving it from events.
2. The TX buffer must be in RAM (as opposed to Flash memory).
Experiment based on libuarte example:
static const uint8_t text[] = "UART example started.\r\nLoopback:\r\n"; ... err_code = nrf_libuarte_async_tx(&libuarte, (uint8_t *)text, text_len); APP_ERROR_CHECK(err_code);
Result:
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Theory: The HW DMA cannot fetch data from ARM I-address space. This might be a HW limitation. For C-code, the physical location of is transparent (e.g. strcpy() can fetch data from Flash and copy it to RAM), the compiler takes care of generating the corresponding code.
Consequently, the application code needs to first copy the Flash data to RAM before calling libuarte.
It would be helpful if someone could confirm these theories.
Thanks,
Norbert
