UART with nRF52832 and FONA 808

RE: UART with nRF52832 and FONA 808

hmolesworth — Mon, 02 Apr 2018 19:53:08 GMT

Good news!

RE: UART with nRF52832 and FONA 808

suprtigr — Mon, 02 Apr 2018 19:13:37 GMT

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.

RE: UART with nRF52832 and FONA 808

suprtigr — Mon, 26 Mar 2018 00:21:35 GMT

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.

RE: UART with nRF52832 and FONA 808

hmolesworth — Sun, 25 Mar 2018 02:33:27 GMT

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).

RE: UART with nRF52832 and FONA 808

suprtigr — Sun, 25 Mar 2018 00:58:26 GMT

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.

RE: UART with nRF52832 and FONA 808

hmolesworth — Sun, 25 Mar 2018 00:50:45 GMT

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.

RE: UART with nRF52832 and FONA 808

suprtigr — Sat, 24 Mar 2018 22:25:49 GMT

I can't verify if it is sending out what is in the buffer either.