RAK5010 UART can't receive from rui_uart_recv

Cellular Boards RAK5010
1

Issue: I can’t receive any data from computer via rui_uart_recv.

Setup: FT232RL 3V3 connected to IO4 and IO3 on RAK5010

Details:
I’ve added a piece of code to user_app.c

void rui_uart_recv(RUI_UART_DEF uart_def, uint8_t *pdata, uint16_t len)
{
    uint16_t i;
    if(!pdata || len < 1){
        APP_PRINT("\r\nUART ERROR");
        goto rui_uart_recv_exit;
    }
    for(i = 0; i < len; ++ i){
        APP_PRINT("\r\nU%u [%c] 0x%02X", (int)(uart_def), pdata[i]);
    }
rui_uart_recv_exit:;
}

APP_PRINT is a known good, it does print data.

I’ve also added some rui_uart_mode_config(RUI_UART1, RUI_UART_USER);, because in some example projects it says rui_uart_recv will only work if uart is in user mode.
Tried different flow control.
Still, I do not receive a single byte.

Transmission on the other hand works perfectly fine. PC receives each and every byte from RAK5010

So if anyone can explain how to connect to the device and/or what am I doing wrong – it would be highly appreciated.
Especially if I get some help before I get fired :slight_smile:

2

hello @stream13 , welcome to the forum.

Did you connect the supply of the FT232RL to the pin EXT_VREF?

Because the nRF52 is powered with 1.8V, there is a voltage converter between the pin headers and the nRF52840. Without supplying EXT_VREF no signal will pass:

image
image1036×487 93.5 KB

Explained in our documentation

3

Yes, I definitely did that and checked the output levels on the pins, which is 3.3V
For now it seems to be a software issue of some sort.

4

@beegee could you please confirm the configuration?

  • it should be RUI_UART1
  • it’s mode should be rui_uart_mode_config(RUI_UART1, RUI_UART_USER);
  • void rui_uart_recv(RUI_UART_DEF uart_def, uint8_t *pdata, uint16_t len) should be implemented, not called.
  • No hardware flow control is required
5

You say, that you can send data using RUI_UART1 but you cannot receive anything?

Can you share your code with me by PM, I will discuss with our engineering what could be the cause.

6

Hi @stream13

Congratulations, you found a glitch in our documentation. :grin:

rui_uart_recv(RUI_UART_DEF uart_def, uint8_t *pdata, uint16_t len) is never called. It should not even be in the documentation.
To receive UART data, you have to do it in at.c because all received UART data is handled by void at_parse(char *cmd).

Look for

if(cmd[0] == 0)
{
	return;
}

and add your received data handler there

Example (not tested)

if(cmd[0] == 0)
{
	// Received data is empty, return
	return;
}    
if(cmd[0] != 'a')
{
	// Received data doesn't start with `a` so it is not an AT command
    uint16_t i;
    if(cmd[0] == 0){
        APP_PRINT("\r\nUART ERROR");
        return;
    }
    int idx = 0;
    while(cmd[idx] != 0){
        APP_PRINT("\r\n0x%02X", cmd[idx++]);
    }
    return;
}
1 Like
7

Hey @beegee
Thank you for the analysis. This explains a lot.
At the moment I’ve figured out how to use SEGGER_RTT_GetKey()
So it’s ok.

But if a more convenient way of inputting the data will be implemented (interrupt-based?) – I would be glad to know!

8

Hi @stream13

Glad you got it to work.

RUI V2 will not get any new features anymore. We are working right now on a complete new RUI version which has many improvements. But no release data available yet.