ESP32 Forum

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 ?

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?

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.

yup.