cancel
Showing results for 
Search instead for 
Did you mean: 

[Bug Report] STM32Cube MCU Package for STM32F0 Series 1.9.0 Error in stm32f0xx_hal_cec.c

Lutz.Tilo
Associate II

Hi

I wrote a little CEC application. Unfortunatly communication with other devices didn't work well.

I used a logic analyzer to find the problem.

The error is in the IRQ function HAL_CEC_IRQHandler:

[...]

 if((reg & CEC_FLAG_TXBR) != RESET)

 {

   if (hcec->TxXferCount == 0U)

   {

     /* if this is the last byte transmission, set TX End of Message (TXEOM) bit */

     __HAL_CEC_LAST_BYTE_TX_SET(hcec);

     hcec->Instance->TXDR = *hcec->pTxBuffPtr++;

   }

   else

   {   

     hcec->Instance->TXDR = *hcec->pTxBuffPtr++;

     hcec->TxXferCount--;

   } 

   /* clear Tx-Byte request flag */

   __HAL_CEC_CLEAR_FLAG(hcec,CEC_FLAG_TXBR);

 }

[...]

The error is in line    if (hcec->TxXferCount == 0U)

Correct is    if (hcec->TxXferCount == 1U)

Else an additional wrong byte is sent. This confuses other members on the bus.

In my case my TV didn'T accept the messages. After the fix everything is fine.

Can anybody confirm this bug?

Is it sufficient to post the bug here or is ther another bug tracker? I havn't found one yet.

Best regards,

Tilo

1 ACCEPTED SOLUTION

Accepted Solutions
Christophe VRIGNAUD
ST Employee

The bug is confirmed and is logged.

The explanation is that when the last byte is going to be transmitted, TxXferCount is still 1, not 0, as it's decremented only after writing TXDR.

But for this reason, the TXBR interrupt will be invoked one additional time (possibly reading past the end of the transmit buffer!) and an unknown value will be appended to the message.

To avoid this, it is better to correct with:

if (--hcec->TxXferCount == 0U) /* pre-decrement the size before the comparison */

Best Regards

Christophe

View solution in original post

1 REPLY 1
Christophe VRIGNAUD
ST Employee

The bug is confirmed and is logged.

The explanation is that when the last byte is going to be transmitted, TxXferCount is still 1, not 0, as it's decremented only after writing TXDR.

But for this reason, the TXBR interrupt will be invoked one additional time (possibly reading past the end of the transmit buffer!) and an unknown value will be appended to the message.

To avoid this, it is better to correct with:

if (--hcec->TxXferCount == 0U) /* pre-decrement the size before the comparison */

Best Regards

Christophe