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

UART with nRF52832 and FONA 808

Hello,

I am attempting to achieve UART Serial Communication with the ADAFRUIT FONA 808 Board, this has a SIM808 Cellular Modem.

I have attempted to re-purpose the examples/peripheral/uart example in SDK 14.2 to no avail. I also tried to re-purpose the BLE UART example to see if I could piggyback on something that I knew would work and instead of the communication go to the PC the communication would go to the FONA 808, however this did not work either.

//#define ENABLE_LOOPBACK_TEST  /**< if defined, then this example will be a loopback test, which means that TX should be connected to RX to get data loopback. */

#define MAX_TEST_DATA_BYTES     (15U)                /**< max number of test bytes to be used for tx and rx. */
#define UART_TX_BUF_SIZE 256                         /**< UART TX buffer size. */
#define UART_RX_BUF_SIZE 256                         /**< UART RX buffer size. */

void uart_error_handle(app_uart_evt_t * p_event)
{
    if (p_event->evt_type == APP_UART_COMMUNICATION_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_communication);
    }
    else if (p_event->evt_type == APP_UART_FIFO_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_code);
    }
}

/**
 * @brief Function for main application entry.
 */
int main(void)
{
    uint32_t err_code;
    uint8_t my_tx_buf[] = {'A','t',0xD}; // ((uint8_t)0x65),((uint8_t)0x84),((uint8_t)0x10)
    uint8_t my_rx_buf[50];
    bsp_board_leds_init();
    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    
    NRF_LOG_INFO("UART 808 example.");

    bsp_board_leds_init();

    const app_uart_comm_params_t comm_params =
      {
          RX_PIN_NUMBER,
          TX_PIN_NUMBER,
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          APP_UART_FLOW_CONTROL_DISABLED,
          false,
          NRF_UART_BAUDRATE_115200
      };

    APP_UART_FIFO_INIT(&comm_params,
                         UART_RX_BUF_SIZE,
                         UART_TX_BUF_SIZE,
                         uart_error_handle,
                         APP_IRQ_PRIORITY_LOWEST,
                         err_code);

    APP_ERROR_CHECK(err_code);

    while (true)
    {
        NRF_LOG_INFO(" Running:");
        uint8_t cr;
        cr = (my_tx_buf[0]);
        //while (app_uart_put(cr) != NRF_SUCCESS)
        app_uart_put(cr);
        cr = (my_tx_buf[1]);
        app_uart_put(cr);
        cr = (my_tx_buf[2]);
        app_uart_put(cr);
        while (app_uart_get(&my_rx_buf) != NRF_SUCCESS){
          nrf_delay_ms(500);
        }
        
        NRF_LOG_HEXDUMP_INFO(my_rx_buf, strlen((const char *)my_rx_buf));
        NRF_LOG_FLUSH();
        nrf_delay_ms(900);//orig 200
        
    }

}

This is the snippet from the latest attempt using the peripheral uart example within the SDK. If someone might be able to point me in the right direction, or explain how I might better do this I would appreciate it. I was able to make SPI work for the most part with an accelerometer and it gave me a lot of confidence before this happened. Too bad I cant use SPI with this.

As far as I can tell, if I can get this going then all I need to do is be able to send ASCII text and receive data back and convert it to ASCII to read.

As a side note I couldn't get the logger working either, but this isn't my main concern.

Parents
  • Might I suggest you disable hardware flow control while getting started? 9600 is so slow it shouldn't be required; if the modem doesn't happen to match HWFC operation then data transfer is blocked. I also suggest the more readable form thus:

    /**@brief  Function for initializing the UART module.
     */
    /**@snippet [UART Initialization] */
    void uart_init(void)
    {
        uint32_t                     err_code;
        app_uart_comm_params_t const comm_params =
        {
            .rx_pin_no    = RX_PIN_NUMBER,
            .tx_pin_no    = TX_PIN_NUMBER,
            .rts_pin_no   = RTS_PIN_NUMBER,
            .cts_pin_no   = CTS_PIN_NUMBER,
            .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
            .use_parity   = false,
            .baud_rate    = NRF_UART_BAUDRATE_115200
        };
    
        APP_UART_FIFO_INIT(&comm_params,
                           UART_RX_BUF_SIZE,
                           UART_TX_BUF_SIZE,
                           uart_event_handle,
                           APP_IRQ_PRIORITY_LOWEST,
                           err_code);
        APP_ERROR_CHECK(err_code);
    }
    /**@snippet [UART Initialization] */
    

    You don't mention pin numbers, but these of course have to match your hardware in case that was overlooked.

    1. Just above my main method UART_HWFC is defined to APP_UART_FLOW_CONTROL_DISABLED. So it definitely should be disabled in my code. I double checked that the pin numbers are correct. They are defined in the pca10040.h file and I am sure that isn't the issue. One of the ideas I had was to ensure that the data transferred included a CR byte, as this is what the Modem is looking for at the end of the command, but it hadn't fixed my issue either. 
  • Ah, you will love this answer! I didn't pick up on the fact you were using the modem to test, so of course you are sending "AT" and expecting "Ok". Only 'A' 'T' is not (uint8_t)0x65),((uint8_t)0x84). Remove the "0x" prefix in each case, or infinitely better simply use 'A' instead of (uint8_t)0x65) which should in any case have been (uint8_t)0x41) or (uint8_t)65).

  • I cant believe that I missed that oversight, I guess that is what I get for not checking what I was getting out of a ASCII-hex converter. I changed my code accordingly and simplified it some. I still haven't been able to communicate let alone get any data into my_rx_buf buffer. Upon boot it should send 00 49 49 49 49 FF FF FF FF but I don't receive that either.

    Edit-Upon further reading it seems that the modem utilizes IRA initially for its communication. Not so bad because ascii is very much similar. However, it made me realize that I might be sending 8bits of data per character and not 7. Would I be correct in this assumption? I saw an Adafruit example that utilized putty with 8 data bit, no parity 1 stop and I am not sure what configuration to use. Also, I added my updated code to original post.

  • It ended up being a combination of things, firstly, and the main thing, I had the TX and RX pins backwards. Found this out utilizing a TTL-USB console cable. Secondly, I was sending the wrong data for the AT command. Thirdly, and I am not sure why this was an issue, sending CR as 0xD was causing issues. I sent it as the int equivalent 13 and it fixed it. So I have consistent comms with my modem now! Thank you.

Reply
  • It ended up being a combination of things, firstly, and the main thing, I had the TX and RX pins backwards. Found this out utilizing a TTL-USB console cable. Secondly, I was sending the wrong data for the AT command. Thirdly, and I am not sure why this was an issue, sending CR as 0xD was causing issues. I sent it as the int equivalent 13 and it fixed it. So I have consistent comms with my modem now! Thank you.

Children
Related