Posted on February 04, 2015 at 20:171. SmartCard USART mode, getting an interrupt for, receiver overrun error (ORE) while transmitting. ORE interrupt before TC interrupt. Causes truncated transmission.
Using
HAL_SMARTCARD_Transmit_IT(
)
The SmartCard UART library code in file stm32f4xx_hal_smartcard.c, line 644 is
/* Enable the SMARTCARD Error Interrupt: (Frame error, noise error, overrun error) */
__HAL_SMARTCARD_ENABLE_IT(hsc, SMARTCARD_IT_ERR);
The above enables irrelevant error interrupts in transmit of half duplex mode. The only valid RX interrupt in this case is parity error, where per ISO7816, the receiving device can pull TX/RX low after a stop bit to signal last-byte-in-error. But receiver overrun makes no sense as in half duplex, we are not receiving, and there are (correctly) no RXNE interrupts.
If I change the line of code above to disable rather than enable, the incorrect overrun error interrupts cease.
Q: What is the solution? Could this be a UART errata item?
Development Hardware: STM32F407 on Discovery board, USART2 in SmartCard mode as established by CubeMX, for ISO SmartCard: 9 bits including 1 even parity.
Q: Will move to STM32F415 for product. Does this have exactly the same USART for SmartCard (HDX) mode?
Tools: CubeMX feeding to IAR, ST-Link debugging. Using HAL code unmodifed, latest.
------------------
2. The transmit complete (TC) interrupt occurs two bytes too early in smartcard mode. Example: One call to
HAL_SMARTCARD_Transmit_IT
()
for 20 bytes will interrupt with TC status after 20 bytes have been sent to the UART but bytes 19 and 20 have not yet been transmitted. I believe that #19 is in the serial shift register and #20 is in the TDR. I see no status bit to say that the last stop bit of the 20th byte has been sent. Therefore, the software does not know when the half-duplex line can be turned-around to RX mode. Other than a brute force time delay from TC for 12 baud clock times (start bit, 9 data bits including parity, 1.5 stop bits per char per ISO7816).
How is this normally handled? Or is this a USART2 problem in the STM32F407 on the Discovery boards? (My eventual target is an STM32F415).
(The guard timer is inter-character times, not post-TC time, so it's not applicable).
Thanks in advance
steve
