AK-SDFS-UART The transmitted message on UART is not good

[davbat]

Hello,
I am working for the first time on Artekit AK-SDFS-UART and I am trying to gather some data through UART from a Renesas chip (RL78-G13).
(Note: I tried the module on Arduino Uno board and it worked perfectly.)
On Renesas chip the problem is that, if I send raw data the things work (the transmitted message is good and the answer is received); otherwise, if I use the Artekit libraries the things do not work (the tx message is not good).

As raw data I tried to send the following commands
static char UartMsgOpen[16] = {0x41, 0x4b, 0x01, 0x0b, 0x08, 0x00, 0x5c, 0x6c, 0x6f, 0x67, 0x2e, 0x74, 0x78, 0x74, 0x35, 0xac};
static char UartMsgCloseAll[8] = {0x41, 0x4b, 0x10, 0x00, 0x00, 0x00, 0x80, 0xc9};
static char UartMsgWrite[11] = {0x41, 0x4b, 0x05, 0x01, 0x03, 0x00, 0x30, 0x0d, 0x0a, 0xe3, 0x54};
static char UartMsgFlush[8] = {0x41, 0x4b, 0x06, 0x01, 0x00, 0x00, 0x8e, 0xc2};

For each command I receive an answer from Artekit module; I inspected the answers through oscilloscope and, in addition, data are correctly written on micro SD.

Here below, an example of message “Close All” is shown (in green the Tx channel and in yellow the Rx channel)

The Renesas API with which I sent the Close all message is the following
HAL_UART_RL78_Send(&debug_uart_com, (uint8_t *)&UartMsgCloseAll, 8);
where the first input is an handle to UART port, the second is the message and the third the size.

Instead, if I use Artekit libraries, the sent message seems to be “corrupted” and the number of bytes lower (3 bytes instead of 8). See pic below

In order to use the Artekit libraries I used the Renesas API “HAL_UART_RL78_Send” inside my_tx_function, as shown below

void my_tx_function(unsigned char* data, unsigned long data_len)
{

HAL_UART_RL78_Send(&debug_uart_com, (uint8_t *)&data, data_len);

}

I inserted a breakpoint inside my_tx_function when the “close all” message is sent. Here below the value of inputs:
data → “AK\020” (that correspond to message 0x41 0x4B 0x10)
data_len = 6
I suppose that the other 3 bytes are zero and that the CRC is computed inside libraries.

Here below the prototype of Renesas function
MD_STATUS HAL_UART_RL78_Send(Uart_com_t *uart_com_p,
uint8_t * const tx_buf,
uint16_t tx_num)

From my analysis I guess that all the inputs of my_tx_function are correct.
So, could you help me to find out the reason why the tx message is not correctly transmitted ?

Thank you.
Best Regards,
David

[Ivan]

Hello @davbat,

Try removing the reference to pointer data. Like this:

void my_tx_function(unsigned char* data, unsigned long data_len)
{
    HAL_UART_RL78_Send(&debug_uart_com, (uint8_t *) data, data_len);
}

[davbat]

Hello @Ivan ,

it seems that nothing has changed.

The message transmitted on Tx channel is the following

The first byte is correct (0x41), but the other not.
0xC9 is a part of CRC…

The full message (CLOSE ALL command) should be 0x41, 0x4b, 0x10, 0x00, 0x00, 0x00, 0x80, 0xc9

As additional info the baud rate is set to 38400 and saved into the module (I did it through Arduino board).

Have you got any suggestion?
Thank you
Regards,
David

[Ivan]

It should work. Not knowing the specific Renesas chip or its API (I did search for that specific function but couldn’t find anything) I can only guess.

I don’t think the missing bytes are zeros, because they are not shown in scope traces. It seems that the transmission is being interrupted somehow.

The library calls the TX callback function at least 3 times for every command (one for header, one for data a one for CRC).

It seems to me that HAL_UART_RL78_Send might be setting the registers to start a first transmission (the message header) and then HAL_UART_RL78_Send is being called again to send the CRC, interrupting the previous transmission and sending the CRC?

I don’t know the Renesas API, but perhaps the HAL wants the transmission to finish before calling another HAL_UART_RL78_Send. Try looking for an API function that blocks while the transmission is ongoing, or put a small delay after HAL_UART_RL78_Send just for testing.

If you can set a breakpoint please check the contents of data (not just the first byte) to see if that data is actually corrupted or it is a matter of the way the chip/API wants to deal with UART transmissions.

[davbat]

Thank you for your suggestion. I investigated more about this issue and I found out that, probably, the Renesas chip has no enough time to transmit data between the three Tx call of Artekit APIs.
So, I added a delay of 2 ms after data transmission, as shown in code below

The picture below shows data collected on Logic Analyzer

As it can be seen, data are all correctly transmitted, but there is delay between the transmission of header (first 6 bytes) and the CRC (last two bytes). So, we have to “remove” that delay…

I identified the Artekit API that is responsible for the transmission

According to your opinion, could I change the API in order to transmit all the bytes in one tx call?
On the other way I could find out another solution investigating more about Renesas tx function.

[Ivan]

Both options are valid. The first option might require allocating the maximum packet size in the function you’ve quoted (header + 512 bytes + crc, in the stack or the heap) to send all possible data in one TX call.

Otherwise you can check if you can wait somehow for the transmission to complete with some Renesas API call, or by checking a register.

[davbat]

Hello @Ivan,
I changed the function fprot_send in order to call the transmit function only one time (which transmits the entire message) and it works!. Here below the portion of code that I changed:

As it can be seen from the image, the three calls have been commented out and now only one call is available at the end of function.
The variable uart_buff_tx contains all the bytes of message (header + data + CRC).
Maybe this code could be useful for other users.

Regards,
David