0
\$\begingroup\$

I have a STM32F765ZITx as master and a STM32F051C8Tx board as slave that im trying to communicated with each other over IrDa. The master is sending 6 bytes (2 startbytes, 1 length of data byte, 1 databyte, 2 checksum bytes) to the slave, which works as a request that the slave is going to transmit back to master a standard reply message containing 14 bytes of data (19 byte including header and checksum). Master transmits every 100ms. My problem is that the slave is receiving the correct header every two samples. This is the situation:

sample 1: 254 251 1
sample 2:  0  251 1
sample 3: 254 251 1 
sample 4:  0  251 1
sample 5: 254 251 1
   .
   .
   .

So the slave is transmitting the standard reply back every two samples.

Here is my init of IrDA on both boards:

static void MX_USART1_IRDA_Init(void)
{
hirda1.Instance = USART1;
hirda1.Init.BaudRate = 9600;
hirda1.Init.WordLength = IRDA_WORDLENGTH_8B;
hirda1.Init.Parity = IRDA_PARITY_NONE;
hirda1.Init.Prescaler = 10;
hirda1.Init.PowerMode = IRDA_POWERMODE_NORMAL;
hirda1.Init.Mode = IRDA_MODE_TX_RX;
}

In my HAL_IRDA_RxCpltCallback(IRDA_HandleTypeDef *hirda) function on the slave side I have a function that handles the received data and calls HAL_IRDA_Transmit_DMA(); to send the standard reply back , before a new HAL_IRDA_Receive_IT(); is called again. I'm not very experienced in this so I am not sure what the "magic" behind these HAL functions do.

Is it bad to call these functions in this order? Are there timing issues when calling transmit and receive in the RX callback function? I have checked that the HAL_IRDA_Transmit_DMA(); is never returning HAL_BUSY. If I remove the transmit function it receives fine.

Anyone have suggestions on why it behaves like this?

\$\endgroup\$
2
  • \$\begingroup\$ Try putting a bigger time gap between successive polls to see if the receiver then behaves. Or set some output on the slave that indicates it is ready to receive. \$\endgroup\$
    – Andy aka
    Commented May 13, 2020 at 16:58
  • \$\begingroup\$ As the previous comment suggested, adding a delay big enough, so the receiving device can react is one option. Normally this is done by interrupts. \$\endgroup\$
    – CFCBazar
    Commented May 13, 2020 at 18:46

1 Answer 1

0
\$\begingroup\$

Noticed that the prescaler was set to 10. Which divides the USART source clock by 10. It was probably too slow to handle the task. Set it to 1 and it works fine

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.