Dear TIC team,
I would like to ask about re-initializing of i.MX6 UART.
My customer is using i.MX6S UART and they need to change UART settings in their application.
When they implemented the re-initialization software without disabling interrupt, they saw the UART did not work as expected after the re-init due to the behavior of interrupt.
Then they added disabling RX interrupt before the re-init process, and UART worked fine after the re-init.
Could you show me whether the adding disabling RX int right before the re-init is reasonable?
Thanks,
Miyamoto
Miyamoto,
Could you please tell which OS is your customer using and also:
- The exact steps to reproduce the problem?
- The patch with their fix
Thanks
Hi Fabio,
OS: i-Tron base
Re-init procedure:
HW_UART_UCR1_CLR(instance,BM_UART_UCR1_RRDYEN); // disable UART RX interrupt
uart_init( instance, baudrate, PARITY_NONE, stopbits, EIGHTBITS, FLOWCTRL_OFF );
uart_set_FIFO_mode( instance, RX_FIFO, 1, IRQ_MODE );
Without the 1st step, disabling RX int, the re-init does not work fine.
Without disabling rx int, interrupt seems to occur repeatedly after the re-init.
the uart_init() function came from your SDK.
BR,
Miyamoto
Hi Fabio,
The customer wants to clarify whether the disabling interrupt is needed when changing UART settings(baud-rate, stop-bit length change).
Do you think the disabling int is not needed always?
BR,
Miyamoto
Hi Miyamoto,
I thought initially your customer was using linux, but this issue I have never seen with linux.
I am not familiar with SDK or i-Tron OS, sorry.
Regards,
Fabio Estevam
Hi AVNET JAPAN FAE
what UART bits they changed during "re-init process",
had UARTEN, RXEN changed?
Best regards
igor
Hi Igor,
Baudrate and length of stop-bit were changed.
BR,
Miyamoto
Hi AVNET JAPAN FAE
seems it may be caused below
Re: i.MX6 UART hardware misbehaves on baudrate mismatch
fixed if bit 7 of UCR3 (ADNIMP in the reference manual) is set.
Best regards
igor