LIBUARTE on ble_app_uart with DMA

RE: LIBUARTE on ble_app_uart with DMA

Jonathan_NB — Wed, 07 Apr 2021 08:30:09 GMT

Hi Barl,

Would you be able to share with me your LIBUARTE on ble_app_uart with DMA example?

Best regards,
Jonathan

RE: LIBUARTE on ble_app_uart with DMA

Sal Garcia — Tue, 12 May 2020 00:30:48 GMT

How did you get this sorted? I have followed your same steps and getting the same error, even with all the correct timer and RTC enabled in sdk_config.h

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Fri, 08 May 2020 06:38:09 GMT

I suggest creating a ticket of your own where you describe your problem in detail. If you think this case is relevant, feel free to link to it in your ticket.

This will make it much easier to get a good overview, as starting over in an already existing thread can get messy quickly.

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

tblock — Thu, 07 May 2020 13:39:49 GMT

Hello,
I am working on a project and need to use DMA and detect end of data reception before the DMA buffer is full. Therefore I tried to start with libuarte.

I have added in sdk_config.h

#define NRF_LIBUARTE_UARTE0 1

#define NRFX_PRS_BOX_4_ENABLED 0

In added

#include "nrf_libuarte_async.h"

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 0, 0, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

to my source code and when I compile I get many compile errors.

I guess I need to define some timers

also I get something like:

7> ../../../../../../components/libraries/balloc/nrf_balloc.h:219:9: sorry, unimplemented: non-trivial designated initializers not supported

So can you tell me what configuration e.g. in sdk_config.h you have used to be able to come some steps further?

I appreciate any hint.

Thanks in advance

Thomas

RE: LIBUARTE on ble_app_uart with DMA

bama — Wed, 08 Apr 2020 14:00:46 GMT

I'm working on a projekt where I also want to use the libuarte but now i have the same issue with the "not enabled time instance" but i have set the instace in sdk_config to true. Can yu please share what you have done to fix this issue?

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Thu, 04 Jul 2019 17:18:21 GMT

Hello,

I have changed the priority interrupt in libuarte_async.c from 1 to 5 and it now works. Work means that it does not stop anymore sending data from the peripheral to the central. The problem now is how these data are sent, because the buffer that I receive from the UART (peripheral side) is changing continuously length.....even if the packet length is fixed and the buffer has same size or bigger (I tried every thing).

Today I saw the post of RoyCreemers, I thought could be same problem so I did what was indicated there....result is that it does not work.

Another problem (very big actually) is that the board works just in debug mode. The weird thing is that even the experiment_libuarte that is in SDK_15.3 does not work in modality DEBUG (On segger embedded studio), but just on Release. Very strange stuff. I think I give up, I cannot spend more time on it even because every day I discover a new bug.

Anyway thanks a lot for your help and your time.

Regards

RE: LIBUARTE on ble_app_uart with DMA

RoyCreemers — Wed, 03 Jul 2019 20:12:13 GMT

Please check the following topic about libuarte:

https://devzone.nordicsemi.com/f/nordic-q-a/48321/using-libuarte-during-flash-operations

We also had some issues with libuarte in combination with soft device. There seemed to be some issues in the code. Nordic provided some patches for this code in this topic.

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Wed, 03 Jul 2019 08:57:21 GMT

You might be seeing a SoftDevice assert because you won't be able to step debug the application code when the SoftDevice is enabled. If you want to step through the code you need to use what is called Monitor Mode Debugging that you can read here. You need to get a return value from sd_ble_gatts_hvx for us to be able to see what exactly goes wrong.

Are you employing double buffering in your application? I found this thread which explains this quite well. Could you try implementing something like that, and fill one RX buffer while the other one is transferring and emptying?

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Tue, 02 Jul 2019 11:44:39 GMT

Hello,

I left the central in the way that it is on SDK 15.3 that Nordic released. The only thing I changed was to commented out the ECHO function in order to do not send back data to the peripheral. My idea was to work before on the peripheral and, once it works, moving on the central.

The program stops here:

SVCALL(SD_BLE_GATTS_HVX, uint32_t, sd_ble_gatts_hvx(uint16_t conn_handle, ble_gatts_hvx_params_t const *p_hvx_params));

Assuming that the packet is long, for example, 75 characters. If I set a rx_buffer of 150 characters, from the "central" side I will see only 2 packets.

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 3, 0, 4, 150, 3);

Basically the programs will call the following function 3 times:

return sd_ble_gatts_hvx(conn_handle, &hvx_params);

the first 2 times it works, in the third it will hang (On the peripheral side).

If I increase the RX_buffer for example at 225 (3x75)

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 3, 0, 4, 225, 3);

the program will call 4 times "sd_ble_gatts_hvx" but on the 4th it will stop. But from this function I cannot get any error because the program never return from there.

The path of the error is:

It will finish in: "Unknown function at 0x00000A60"

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Fri, 28 Jun 2019 06:03:36 GMT

What about the RX buffer on the central side? Do you clear that one after printing as well, or does it just fill up?

Have you stepped through your code to see why you never reach the APP_ERROR_CHECK()? If you set the check outside of the if-loop so you get it no matter what the error code, you should be able to see it.

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Thu, 27 Jun 2019 12:05:21 GMT

Hi,

I do not use any TX buffer (not that I know). Because in this case I'm not writing on the UART, I'm just reading, sending to the central and make free the RX buffer.

I cannot get an error code. In the code that I put back here, there is APP_ERROR_CHECK(err_code), but the program does not go there.

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
    uint32_t       err_code;
    ret_code_t ret;

    switch (p_evt->type)
    {
        case NRF_LIBUARTE_ASYNC_EVT_ERROR:
            bsp_board_led_invert(1);
            break;
        case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
            bsp_board_led_invert(2);
            err_code= ble_nus_data_send(&m_nus, p_evt->data.rxtx.p_data, &p_evt->data.rxtx.length, m_conn_handle);
            do
            {
                if ((err_code != NRF_ERROR_INVALID_STATE) &&
                    (err_code != NRF_ERROR_RESOURCES) &&
                    (err_code != NRF_ERROR_NOT_FOUND))
                {
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_RESOURCES);
            nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);    // if I remove this line of code I will have more or less the same behavior 
            break;
        case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
            bsp_board_led_invert(3);
            break;
        default:
            break;
    }
}

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Tue, 25 Jun 2019 13:32:15 GMT

Thank you for the clarification! Is by any chance the TX buffer not cleared after sending a message, and that is what is causing this error? If not, are you able to get an error code so we can see where exactly this error originates?

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Tue, 25 Jun 2019 10:20:05 GMT

Hi Simonr,

In this moment I'm able to receive the data from the micro-controller to the peripheral via UART (I'm sending a fixed length packet from micro to peripheral). Once that I receive this packet I've tried to do 2 things:

1) The peripheral receive the DATA from the micro-controller via UART and print them again on its own UART (I print the packet received on the terminal, in order to have a visual of what is happening and if the peripheral is receiving good the data from the micro-controller).

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
    uint32_t       err_code;
    ret_code_t ret;

    switch (p_evt->type)
    {
        case NRF_LIBUARTE_ASYNC_EVT_ERROR:
            bsp_board_led_invert(1);
            break;
        case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
            bsp_board_led_invert(2);
            ret = nrf_libuarte_async_tx(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
            nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);    // if I remove this line of code I will have more or less the same behavior 
            break;
        case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
            bsp_board_led_invert(3);
            break;
        default:
            break;
    }
}

The important code lines are:

- ret = nrf_libuarte_async_tx(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
- nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);

In this case it works perfectly (It means I can see on the terminal the packet that I'm sending from the micro-controller).

For instance, if I comment out the line where I make free the buffer:

- ret = nrf_libuarte_async_tx(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
- // nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);

What will happen is that I will see on terminal a number of packets that is proportional to the RX buffer before to stop working. Rx that I set here:

- NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 0, 3, 0, 4, "RX", 3);

It means that, if I have a bigger RX buffer I'll see more packet on the terminal before it stops.

Conclusion on this point:

- If I want to print on terminal what I' m receiving from micro-controller is important to make free the RX buffer. In that case everything is working good and reliable.

2) The peripheral will send the packets that it receives, from the micro-controller via UART, to the central over bluetooth. The central, once got the packet, will print it on the terminal.

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
    uint32_t       err_code;
    ret_code_t ret;

    switch (p_evt->type)
    {
        case NRF_LIBUARTE_ASYNC_EVT_ERROR:
            bsp_board_led_invert(1);
            break;
        case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
            bsp_board_led_invert(2);
            err_code= ble_nus_data_send(&m_nus, p_evt->data.rxtx.p_data, &p_evt->data.rxtx.length, m_conn_handle);
            do
            {
                if ((err_code != NRF_ERROR_INVALID_STATE) &&
                    (err_code != NRF_ERROR_RESOURCES) &&
                    (err_code != NRF_ERROR_NOT_FOUND))
                {
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_RESOURCES);
            nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);    // if I remove this line of code I will have more or less the same behavior 
            break;
        case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
            bsp_board_led_invert(3);
            break;
        default:
            break;
    }
}

Important lines:

- err_code= ble_nus_data_send(&m_nus, p_evt->data.rxtx.p_data, &p_evt->data.rxtx.length, m_conn_handle);
- nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);

In this case the peripheral start to sends packets to the central, but after a while it stops and crash.

The number of packets sent, like in the 1) case, is proportional to the RX buffer size that I've set here:

- NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 0, 3, 0, 4, "RX", 3);

All of this happens without commenting out:

- nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);

So, it's like that the RX_buffer cannot be cleaned once that I send data over bluetooth with "ble_nus_data_send".

So, my problem is that when I try to send the packet from the peripheral to the central over bluetooth, it stops after a while. The behaviour in the case 2 is the one where I'm asking you help. The case 1 is just a case where the problem seems to have the same behaviour once that I comment out the "nrf_libuarte_async_rx_free".

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Tue, 25 Jun 2019 08:33:07 GMT

I'm having some trouble understanding what exactly you mean. Is it the UART or the BLE communication you're having trouble with? It seems to me that you're able to receive the UART data filling up your buffer to the peripheral, and then sending this data to the central. Are you having trouble clearing the RX buffer from the peripheral before receiving a new "batch" of UART data?

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Mon, 24 Jun 2019 17:44:57 GMT

Hi All,

I have partially solved the problem. When I try to send the data over Bluetooth, from the other side I get them, but the peripheral stops at certain point to send data.

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
    uint32_t       err_code;
    ret_code_t ret;

    switch (p_evt->type)
    {
        case NRF_LIBUARTE_ASYNC_EVT_ERROR:
            bsp_board_led_invert(1);
            break;
        case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
            bsp_board_led_invert(2);
            err_code= ble_nus_data_send(&m_nus, p_evt->data.rxtx.p_data, &p_evt->data.rxtx.length, m_conn_handle);
            do
            {
                if ((err_code != NRF_ERROR_INVALID_STATE) &&
                    (err_code != NRF_ERROR_RESOURCES) &&
                    (err_code != NRF_ERROR_NOT_FOUND))
                {
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_RESOURCES);
            nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);    
            break;
        case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
            bsp_board_led_invert(3);
            break;
        default:
            break;
    }
}

Exactly sends the data based on the size of the buffer when I define the NRF_LIBUARTE (the RX in this case). The larger the buffer the greater the number of packets sent, then it stops to send packets.

NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 0, 3, 0, 4, "RX", 3);

The same thing happen if for example, in stead to send the data received from UART to the central, I print them again on the UART of the peripheral and I do not make free the RX buffer:

"nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length); "

See the code below:

void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
    nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
    uint32_t       err_code;
    ret_code_t ret;

    switch (p_evt->type)
    {
        case NRF_LIBUARTE_ASYNC_EVT_ERROR:
            bsp_board_led_invert(1);
            break;
        case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
            bsp_board_led_invert(2);
            ret = nrf_libuarte_async_tx(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
//          err_code= ble_nus_data_send(&m_nus, p_evt->data.rxtx.p_data, &p_evt->data.rxtx.length, m_conn_handle);
            do
            {
                if ((err_code != NRF_ERROR_INVALID_STATE) &&
                    (err_code != NRF_ERROR_RESOURCES) &&
                    (err_code != NRF_ERROR_NOT_FOUND))
                {
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_RESOURCES);
            nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);    // if I remove this line of code I will have more or less the same behavior 
            break;
        case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
            bsp_board_led_invert(3);
            break;
        default:
            break;
    }
}

Any help is appreciated ;) 🙃🙃

Thank you all 🙂🙂🙂

RE: LIBUARTE on ble_app_uart with DMA

run_ar — Thu, 13 Jun 2019 11:24:01 GMT

Hi,

I have to admit it's been a while since I worked with libuarte. but the Libuarte driver is a bit special given that it uses a timer to stop RX if the peer does not send date for a certain amount of time. This means that if you send multiple short packets with a given delay inbetween your application might not be able to read the data from the RX buffer before it is switced to the next buffer and then back again. the pointer for DMA will typically be updated between the rx events. Also this means that the other part of the uart communication has to respect these limitations. so if it want to send a lot of data to one buffer that has to be completed within a certain time (you cannot wait to send more data as the rx timer will expire). Or if you want to send short packets you have to wait for the timeout to occur, before sending the next one.

If it's possible to use HW flow control, you could disable the timer and use that instead. Not sure if this is possible with the driver at this stage. Note that the timeout was added to make it possible to transimt at high baudrates without hwfc.

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Tue, 11 Jun 2019 22:07:02 GMT

Hello,

I managed to implement libuarte in ble_app_uart and, finally I have no problems compiling and I can send data from the "peripheral" to the "central".

Obviously sending the data I have a lot of errors yet that I hope you will be able to help me.

For now I have focused only on the "peripheral" side, which means that the central remained as from SDK 15.3 (except for the fact that I removed the ECHO of the data, so the data received are not sent back).

Of course I’ve modified something in the sdk_config.h and the main in the ble_app_uart example.

In the MAIN, compare to the ble_app_uart example, I’ve changed the init of the UART:

//UART INIT:
…………………
NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 3, 0, 4, 75, 3);
………………………………………………………..

static void uart_init(void)
{
nrf_libuarte_async_config_tnrf_libuarte_async_config = {
                  .tx_pin     = TX_PIN_NUMBER,
                  .rx_pin     = RX_PIN_NUMBER,
                  .baudrate   = NRF_UARTE_BAUDRATE_115200,
                  .parity     = NRF_UARTE_PARITY_EXCLUDED,
                  .hwfc       = NRF_UARTE_HWFC_DISABLED,
                  .timeout_us = 100,
          };

ret_code_terr_code = nrf_libuarte_async_init(&libuarte, &nrf_libuarte_async_config, uart_event_handler, &libuarte);

          APP_ERROR_CHECK(err_code);

nrf_libuarte_async_enable(&libuarte);

}

and the "void uart_event_handler" method which I report below:

/**@snippet [UART Initialization] */

//UART_EVENT_HANDLER:
void uart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
        nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;
            uint32_t       err_code;
        ret_code_t ret;
        
        
        switch (p_evt->type)
            {
                    case NRF_LIBUARTE_ASYNC_EVT_ERROR:
                        bsp_board_led_invert(0);
                        break;
                    case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
                    	ret=nrf_libuarte_async_tx(p_libuarte,  p_evt->data.rxtx.p_data , p_evt->data.rxtx.length);
                    	bsp_board_led_invert(2);
                    
                    //	do
                    //                    {
                    //                        uint16_t length = (uint16_t)index;
                    //                        err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
                    //                        if ((err_code != NRF_ERROR_INVALID_STATE) &&
                    //                            (err_code != NRF_ERROR_RESOURCES) &&
                    //                            (err_code != NRF_ERROR_NOT_FOUND))
                    //                        {
                    //                            APP_ERROR_CHECK(err_code);
                    //                        }
                    //                    } while (err_code == NRF_ERROR_RESOURCES);
                    
                    	nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data,p_evt->data.rxtx.length);
                    	break;
                    case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
                        bsp_board_led_invert(3);
                        break;
                        default:
                        break;
            }
}

The idea is:

Write from microcontroller on the peripheral UART, the peripheral receives and sends to the central. Before doing this, or using the "ble_nus_data_send" I would like to see what happen in the peripheral side, so,once I received the data on the UART, instead to use "ble_nus_data_send" (that for sure once I remove the comments will give some problem),I print everything on the peripheral UART terminal with "nrf_libuarte_async_tx".

If with a microcontroller I send a string of "N" characters that ends with "\n" every "s" m_seconds what should happen is:

As is the program, (considering the commented lines) once the string is received it is printed. The problem is that what I print is not exactly what I send, but it is like that in the buffer something is stored and something is repleced from a new data.

If I'm sending a buffer like this:

ABCDEFG\n, for instance I get something "similar":

ABCDEFG\n

ABCDEFABCDEFGABCDEFGABCDEFG\n

ABCABCDEFG\nABCDEFG

ABCDEFG\n

I do believe that is something releated to the size of the buffer here:

"NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 3, 0, 4, 75, 3);"

But, if I try with the experimental_libuarte it works perfectly. In that example I modified few rows that I report here:

MAIN experimental_libuarte:

voiduart_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt)
{
nrf_libuarte_async_t * p_libuarte = (nrf_libuarte_async_t *)context;

ret_code_t ret;

switch (p_evt->type)
    {
case NRF_LIBUARTE_ASYNC_EVT_ERROR:
bsp_board_led_invert(0);
break;
case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:
bsp_board_led_invert(1);
ret = nrf_libuarte_async_tx(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
nrf_libuarte_async_rx_free(p_libuarte, p_evt->data.rxtx.p_data, p_evt->data.rxtx.length);
break;
case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:
bsp_board_led_invert(2);
break;
default:
break;
    }
}

This works perfectly.

What am I doing wrong?

Am I missing something?

To be honest, I didn't understand how the buffer (DMA size etc) works. Can you help me?

For instance, I would like the characters to be stored in the DMA buffer (which I don't know how to access), and an interrupt to be triggered only when the buffer is filled. Once that the interrupt happens the program goes into the event handler routine in the main and I print the buffer.

- Another thing is that with the ble_app_uart that I modified, the board works just in debug. If I just flash it in Release or Debug and then I try to use, it does not work.

-The experimental_libuarte that you released in SDK15.3 in "DEBUG" mode goes directly to NRF_BREAKPOINT_COND, in Release no.

Thanks

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Wed, 29 May 2019 15:09:22 GMT

Sorted..... :)

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Wed, 29 May 2019 13:57:52 GMT

Hello

I got errors in build solution, but I do not how I can solve them.

I've just imported the libraries and drivers missing (nrfx_PPI, nrf_rtc, nrf_timer, libuarte, libuarte_async) and then I enabled some stuff (following Libuarte experiment) in sdk_config.

What those errors can be?

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Wed, 29 May 2019 07:39:05 GMT

Hello

I don't know what exactly to assist you with here, as you will just have to work through these errors until you have the libuarte configured correctly. If you get stuck on anything specific, I will, of course, help you out, but this process is something you will have to go through and fix yourself.

Best regards,

Simon

RE: LIBUARTE on ble_app_uart with DMA

Bar1 — Tue, 28 May 2019 15:21:48 GMT

Hi,

I modified the experiment_libuarte for my needs, but when I try to import it in the ble_app_uart I have many many many problems that really I do not know to figure them out. I tried to import the libraries like "nrf_libuarte.h", "nrf_libuarte.c", "nrf_libuarte_async.h".....

I tried to modify something in sdk_config of ble_app_uart following the setup of sdk_config in experimental_libuarte.

In the main of ble_app_uart I removed the previous "uart_event_handle" and replaced it with the one that is in experimental_libuarte (a bit changed for my needs) and then send everything using ble_nus_data_send.

When I try to build the solution, FOR THE MOMENT, I get these 2 errors:

- static assertion failed: "Timer instance not enabled"

- 'NRFX_TIMER0_INST_IDX' undeclared here (not in a function); did you mean 'NRFX_TIMER_INSTANCE'?

but I' m sure that I'll get something else going forward.

RE: LIBUARTE on ble_app_uart with DMA

Simonr — Fri, 24 May 2019 08:39:29 GMT

This shouldn't be too hard to accomplish. I suggest you start out with the ble_app_uart example, and implement/replace the UART/UARTE functions with the experimental_libuarte example functions. This post is very thorough on the matter of LIBUARTE if anything is unclear, and has a few tips on what to stay alert on when using the peripheral, so I suggest a read through there as you go along.

For example, be aware that LIBUARTE requires NRFX_PRS_BOX_4 to be disabled for the UARTE0 peripheral since it needs to use its own LIBUARTE UARTE0_UART0_IRQHandler, as it is not fully integrated in the SDK yet.

Now, we don't have a finished example where LIBUARTE is integrated in the ble_app_uart example, so you will have to do this yourself, or if you're lucky, someone on the forum has already made something similar and are willing to share.

Best of luck and regards,

Simon