Greetings,
SoC platform:esp32-U4WDH
idf version:v4.4
After reading the esp32 SoC errata, I come up with a question regarding the problem stated in section 3.21. It says when cpu reading five specific FIFO register addresses, if interrupts occur, the reading process will be interrupted and subsequent cpu access to these registers will also fail. To confront this, interrupts should be disabled before reading these FIFO registers and then enabled again.
In my current project, UART2 communication and gpio interrupt are both covered. For UART communication, I use uart_read_bytes() provided in idf and for interrupt, I register an IRAM-safe ISR with gpio edge triggered and flags ESP_INTR_FLAG_LEVEL3 and ESP_INTR_FLAG_IRAM. The interrupt is always enabled no matter which states the UART commnication is in. So far the program works smoothly which is somehow beyond my expectations since the interrupt is triggered quite often and I am sure there would be some time point at which program reads UART data and an interrupt occurs.
To make sure if the situation mentioned in section 3.21 could potentially happens in my case, I checked the code of uart_read_bytes(). If I understand it correctly, the function doesn't read UART FIFO register directly, instead it just moves data out from rx_ring_buffer and if there is no data in the ring buffer, it returns. The rx_ring_buffer is filled when a UART interrupt with event UART_INTR_RXFIFO_TOUT or UART_INTR_RXFIFO_FULL or UART_INTR_CMD_CHAR_DET is triggered. The UART interrupt ISR calls uart_hal_read_rxfifo() to move data from rx FIFO register to an intermediate buffer and then to the rx_ring_buffer. uart_hal_read_rxfifo() essentially accesses rxfifo_rd_byte to get FIFO data. So the points that confuse me are:
1. The rxfifo_rd_byte register that uart_hal_read_rxfifo() accesses is actually 0x3FF6E000 for UART2 mentioned in section 3.21. Is this right?
2. If above is right, why the problem stated by section 3.21 does not occur when cpu accesses 0x3FF6E000 and an gpio interrupt is triggered?
3. Is the reason to above that cpu accesses the FIFO register in an interrupt so the process does not get interrupted by another interrupt?
4. If above is right, is the UART ISR default priority higher or equal to level3?
5. If I want to read UART data directly from rx FIFO in the normal program flow not in an interrupt, all interrupts should be diabled in advance just like section 3.21 stated in its workarounds. Is this right?
Thanks for your time and attention.
Best regards
Interrupt occurs during cpu reading uart rx fifo register mentioned in esp32 SoC errata 3.21
Who is online
Users browsing this forum: Baidu [Spider] and 293 guests