app_uart_put

[control]

Hi everyone

I am using app_uart_put() method for sending data via UART. The problem is that when I send each byte I get each byte back to its event handler in APP_UART_DATA_READY state. I would like to get only received data on APP_UART_DATA_READY state. I will appreciate for help in advance.

[Karl Ylvisaker]

Hello,

The problem is that when I send each byte I get each byte back to its event handler in APP_UART_DATA_READY state.

The APP_UART_DATA_READY is used to alert the application that data has been received and placed in the RX buffer.
Are you performing a loopback test? Or, is your TX pin connected to your RX pin?
If not, please elaborate on how you device is connected, and to what it is connected.

Is it possible that the other device you are transmitting to is just transmitting anything it receives?
Is your project based on any of the examples from the SDK? If so, which example, and what modifications have you made to it?

Looking forward to resolving this issue together,

Best regards,
Karl

[control]

Our ble module is connected to the cellular module via UART.  If I send the commands from RealTerm I get the following response (in this case ble module is disconnected):

+CEREG=5
OK

+CHTTPCREATE="">http://xxxxxxxxx"
+CHTTPCREATE: 0
OK

if the connect the same cellular modul on the ble module I get:

AT+CEREG=5
OK

AT+CHTTPCREATE="http://xxxxxxxxx"

 +CHTTPCREATE: 0

Why AT prefix is added in both commands, the same is true for other commands as well? The code for UART I copy/past from UART ble example for a peripheral unit.

[Karl Ylvisaker]

Hi,

control said:

If I send the commands from RealTerm I get the following response (in this case ble module is disconnected):

What do you mean when you are saying that the BLE module is disconnected? Is it not the nRF device you are sending UART commands from?

The log you have provided does not tell me much. Which direction is the messages send, and how does the response differ from what you had expected?

control said:

Why AT prefix is added in both commands, the same is true for other commands as well?

AT Commands are instructions used to control a modem, which by the looks of it is what you are trying to do. You can read an introduction to them here.

control said:

The code for UART I copy/past from UART ble example for a peripheral unit.

From your original ticket, it seemed you had a problem with getting the UART peripheral to function properly. Is this no longer the case - is the UART behavior now as expected, and you have encountered new issues with the results of the commands sent over UART?

Best regards,
Karl 

[control]

It seems that I was a little bit quicker. We have the cellular module which can be connected via UART

1) directly on PC

or

2) directly on nrf52811.

In the first case, I send AT commands AT+CEREG=5 and AT+CHTTPCREATE="xxxxxxxxx" via PC on the cellular module. For this purpose, I used RealTerm and I got a response as shown in the previous post. In the second case, I try to send the same commands via UART from nrf52811 on the cellular module and I got a different response for the same commands. When the commands are sent via nrf52811 I get back on APP_UART_DATA_READY entire command as you can see from the previous post. Every time I get prefix AT. This is not true if the commands are sent via the RealTerm. Due to this fact, I suspect that app_uart_put() method maybe cause some problems.

Thanks in advance

Samo

[Karl Ylvisaker]

Hello Samo,

Thank you for clarifying.

control said:

Due to this fact, I suspect that app_uart_put() method maybe cause some problems.

Do you have access to a logic analyzer, so that you may see what is happening on the UART pins?

control said:

via PC on the cellular module. For this purpose, I used RealTerm and I got a response as shown in the previous post.

Is the behavior of the cellular modem as expected when you send the command from your RealTerm terminal?
Could you share the code you have implemented for sending the UART commands from the nRF52811?

control said:

When the commands are sent via nrf52811 I get back on APP_UART_DATA_READY entire command as you can see from the previous post.

How is your UART pins connected to the modem? Have you made sure that you have not enabled the loopback testing in the UART peripheral example?
It sounds very strange to me that you are immediately receiving the same UART transmission that the device itself sent - so either it is in loopback, or the other device is deliberately sending the same command back again, which also would be unexpected.

Looking forward to resolving this issue together,

Best regards,
Karl

[control]

Hi Karl,

thanks for your help. I am pretty sure that RealTerm works fine. For example, if I send "AT\r\n" I get back "OK" on REalTerm. If I do the same via the ble module I get back "AT\r\n OK ". At the moment I do not get access to a logic analyzer. 

I do not use a basic peripheral example I use ble peripheral example.

       ...
       sending_data_uart("AT\r\n", 4);
       err_code = app_timer_start(sending_data_to_server_id, INTERVAL_2500MS ,NULL);
       APP_ERROR_CHECK(err_code);
       ...
       

void sending_data_uart(uint8_t * data, uint16_t len)
{
    uint32_t err_code;

    for (uint16_t i = 0; i < len; i++)
    {
        
        do
        { 
            
            err_code = app_uart_put(data[i]);
            if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
            {
                NRF_LOG_ERROR("Failed Error 0x%x. ", err_code);
                APP_ERROR_CHECK(err_code);
            }
        } while (err_code == NRF_ERROR_BUSY);        
    }    
}

The inner resistor is used for Rx pin. It is achieved by applying the following code after uart_init()- 

 nrf_gpio_cfg(RX_PIN_NUMBER, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_NOSENSE);

It is not a secret that our cellular module is SIMCOM 7020 which is connected with ble module via UART. Do you think that I have a problem because I use RTT for logging?

NRF_LOG_BACKEND_RTT_ENABLED 1

I really do not know what can be wrong I spend a few days and I did not figure out what is going on.

[Karl Ylvisaker]

Hello Samo,

control said:

thanks for your help.

No problem at all, I am happy to help!

control said:

I am pretty sure that RealTerm works fine. For example, if I send "AT\r\n" I get back "OK" on REalTerm. If I do the same via the ble module I get back "AT\r\n OK ".

Could you tell me more about how the boards and computer is connected?
When you say that you are seeing the incorrect "AT\r\n OK " from the BLE module, are you seeing this on an RTT terminal? 

control said:

The inner resistor is used for Rx pin. It is achieved by applying the following code after uart_init()- 

By this, you mean that you are engaging the PULL UP resistor of the RX pin, correct?
Is there a reason why you are only doing this on the RX pin - is this specified by your cellular modem?
Could you confirm for me that you are not receiving any errors from your nordic driver functions?
Please make sure that you perform an APP_ERROR_CHECK on the return values of all nordic driver functions, and that you have DEBUG defined in your preprocessor defines, as shown in the included image:

control said:

It is not a secret that our cellular module is SIMCOM 7020 which is connected with ble module via UART. Do you think that I have a problem because I use RTT for logging?

It should not be a problem no - if your connections are correct, and you are not in fact interfering with your UART communications this way.
Are you able to see the logger outputs to the RTT "debug terminal" in Segger Embedded Studios?

control said:

NRF_LOG_BACKEND_RTT_ENABLED 1

This is correct, but could you also show me all your other NRF_LOG_* defines?
If you are building this code on the foundation of the ble_app_uart example then the logger configurations should be fine, since this example uses RTT logging ( since the UART peripheral is used by the application itself ).

I am looking forward to resolving this issue together!

Best regards,
Karl