• State Verified Answer
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 207 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339730
Options

Bytes are lost when sending with nrfx_uarte_tx in uarte_handler

SvenSi

Hello,

I´m trying to send a paket of databytes. For some reasons I need to send it byte by byte (that´s not changeable).

I have inited the uarte with a handler:

nrfx_uarte_init(&m_uarte1_inst, &m_uarte1_config, uarte1_handler);

The first byte is sent in the main-thread. After that I´m using the handler for the following bytes.

In the handler I´m checking the event-Type and on EVT_TX_DONE I´m trying to send the next byte.

switch (p_event->type)
  {
  case NRFX_UARTE_EVT_ERROR:
...
    break;

  case NRFX_UARTE_EVT_RX_DONE:
    ...
    break;

  case NRFX_UARTE_EVT_TX_DONE:
    LOG_DBG("HW %02x", txData);
    ret = nrfx_uarte_tx(p_current_uarte, &txData, 1, 0);
    if (ret != NRFX_SUCCESS)
    LOG_DBG("TX-Error");
    break;

Sometimes there are Bytes missing in the transmission (checked with a logic-analyser at the output-pin). In the LOG I can see the bytes correctly. And there are no "TX-Error"-Messages. So the bytes seems to be transmitted to the uarte-peripheral correctly, but it are not always sent out.

Are there any hints that I could follow?

Parents
  • 0

    Yes, it seems to be a timing problem. I tested to use a workqueue to send the next byte. This seems to be ok, but now there is a delay between the bytes (as expected), so I would like to get it back to the ISR.

    Could you explain it more detailed why it is a problem to use the function in the interrupt context? Is there a function that can be used?

  • +1 in reply to SvenSi
    SvenSi said:
    Could you explain it more detailed why it is a problem to use the function in the interrupt context? Is there a function that can be used?

    As you can see in nrfx_uarte_tx(), the function has some loops waiting for stuff. In other words, it is blocking. And blocking functions is generally not a good idea in an interrupt context.

    SvenSi said:
    Yes, it seems to be a timing problem. I tested to use a workqueue to send the next byte. This seems to be ok, but now there is a delay between the bytes (as expected), so I would like to get it back to the ISR.

    The delay is likely because the workqueue is scheduled by the Zephyr scheduler. To make it faster, either do not use the scheduler but a polling function and global variable or semaphore to be really fast, or give the workqueue a higher priority.

Reply
  • +1 in reply to SvenSi
    SvenSi said:
    Could you explain it more detailed why it is a problem to use the function in the interrupt context? Is there a function that can be used?

    As you can see in nrfx_uarte_tx(), the function has some loops waiting for stuff. In other words, it is blocking. And blocking functions is generally not a good idea in an interrupt context.

    SvenSi said:
    Yes, it seems to be a timing problem. I tested to use a workqueue to send the next byte. This seems to be ok, but now there is a delay between the bytes (as expected), so I would like to get it back to the ISR.

    The delay is likely because the workqueue is scheduled by the Zephyr scheduler. To make it faster, either do not use the scheduler but a polling function and global variable or semaphore to be really fast, or give the workqueue a higher priority.

Children
No Data
Related
Terms of service