This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Sending via Uart

Hi, I need to be able to communicate between two boards via UART. I had a look at the example from Ole provided here: devzone.nordicsemi.com/.../ as well as other references here on the Dev zone and code examples in the SDK.

I am running the PCA10001 and also tested it on the N5 chip from Dynastream. The chip is using SDK v6.1 and SD s110 v7.

I need to use hardware flowcontrol and to simplify things I am currently testing it against a PC. Using Ole's code and importing it into a clean IAR project and running it on the PCA10001 the software goes into the app_error_handler after trying to run app_uart_put for the second time, the reason is a NRF_ERROR_NO_MEM error as the current state is not UART_READY. This happens for both HFC on/off.

uint8_t len = strlen((char *) str);
for (uint8_t i = 0; i < len; i++)
{
    APP_ERROR_CHECK(app_uart_put(str[i]));
}

Here is a copy of the app_uart_put function from app_uart.c

uint32_t app_uart_put(uint8_t byte){
    uint32_t err_code = NRF_SUCCESS;

    if (m_current_state != UART_READY)
    {
      err_code = NRF_ERROR_NO_MEM;
    }
    else
    {
      m_tx_byte = byte;
      on_uart_event(ON_UART_PUT);
    }

    return err_code;
}

By adding something like this into the app_uart_put function the problem is solved but I would rather not want to change the SDK. Could also put a fixed delay into the send function but that is an even worse hack in my opinion.

while (m_current_state != UART_READY)
{
    // Wait until uart is ready again
}

Am I using the framework incorrectly or can someone suggest a cleaner solution for this issue, the best thing would be to be able to use the app_uart library from the SDK without modification for future releases.

Thanks!

Parents
  • Which version of the nRF51822 are you using. There was an increase in the UART buffers between revision 1 and revision 2 of the chip from 2 byte to 6 bytes.

    nRF51822 QFAAC0 is first revision. nRF51822 QFAAG0 is second revision.

    You have at least two nRF51822 or are you planning on having two different UART chips talking to each other? What's the setup you are actually looking for?

  • I do see the concern that you don't want to modify the UART example, but here you are writing faster than you are sending and you have to take care not to overflow the TX buffer. So the wait operation should improve the situation as you see. How are the flow control pins behaving during this? Are you getting feedback indicating that the UART is ready to send more?

    SIDENOTE: I might have side tracked you since you have problems with the TX buffer and I was talking about the receiver buffer. Just to clarify I would like to follow up anyways. If you have nRF51822 with the G0 version mentioned above I would recommend you to try out your setup on that one to see if the extra buffer size would solve your issue.

    I'm not sure which version of the nRF51422 that Dynastream are using/have used on their N5 modules, but it could potentially be an elder version of this module you have with a first revision of the nRF51422. This could be easily identified by whether or not you are able to program softdevice on the module or not. The first version of the nRF51422 had the ANT softdevice/stack hardcoded onto ti. If you can program a different softdevice to the module, you have revision 2 of the chip and the additional UART buffer.

Reply
  • I do see the concern that you don't want to modify the UART example, but here you are writing faster than you are sending and you have to take care not to overflow the TX buffer. So the wait operation should improve the situation as you see. How are the flow control pins behaving during this? Are you getting feedback indicating that the UART is ready to send more?

    SIDENOTE: I might have side tracked you since you have problems with the TX buffer and I was talking about the receiver buffer. Just to clarify I would like to follow up anyways. If you have nRF51822 with the G0 version mentioned above I would recommend you to try out your setup on that one to see if the extra buffer size would solve your issue.

    I'm not sure which version of the nRF51422 that Dynastream are using/have used on their N5 modules, but it could potentially be an elder version of this module you have with a first revision of the nRF51422. This could be easily identified by whether or not you are able to program softdevice on the module or not. The first version of the nRF51422 had the ANT softdevice/stack hardcoded onto ti. If you can program a different softdevice to the module, you have revision 2 of the chip and the additional UART buffer.

Children
No Data
Related