Hi,
I'm trying to figure out the reason behind the NOP in ESP32 uart_ll_read_rxfifo
https://github.com/espressif/esp-idf/bl ... _ll.h#L203
Is this related to esp32 errata 3.16 ?
esp32 UART FIFO read
Re: esp32 UART FIFO read
The wording in errata 3.16 (plural workarounds) would seem to imply that you either need to use a memw instruction / volatile keyword (which should be handled by the READ_PERI_REG macro), or insert 7 NOPs.
So it doesn't explain this NOP (using READ_PERI_REG should be enough), or is there another reason behind it ?
Unless the errata actually describes two steps of a single workaround?
So it doesn't explain this NOP (using READ_PERI_REG should be enough), or is there another reason behind it ?
Unless the errata actually describes two steps of a single workaround?
-
- Posts: 1708
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: esp32 UART FIFO read
It seems that MEMW would solve the speculative/lost access but maybe not the FIFO pointer update timing issue. Given that the NOP is only conditionally used when compiler optimizations are on, I guess that someone found that the "worst-case" (i.e. fastest) iteration time for this particular loop when optimized was just short of the time required.
It's also possible that the single volatile asm statement just serves to prevent gcc from doing certain optimizations, thus achieving the minimum iteration timing required.
It's also possible that the single volatile asm statement just serves to prevent gcc from doing certain optimizations, thus achieving the minimum iteration timing required.
Who is online
Users browsing this forum: NevynSelby and 85 guests