Description
Basic Infos
- This issue complies with the issue POLICY doc.
- I have read the documentation at readthedocs and the issue is not addressed there.
- I have tested that the issue is present in current master branch (aka latest git).
- I have searched the issue tracker for a similar issue.
- If there is a stack dump, I have decoded it.
- I have filled out all fields below.
Platform
- Core Version: 2.6.x +
Problem Description
Ref: I2C stability
Per discussions with @Tech-TX and @earlephilhower, it looks like inline ICACHE_RAM_ATTR functions in conjunction with compiler optimizations can cause crashes. Specifically, the current state (prior to either of the two PRs above) seems to be that the compiler decides to break up Twi::reply() into parts (ref here ) , and then the attribute doesn't get propagated to all the parts correctly. Of course, any part of reply() that is not in IRAM can cause a crash.
PR #6898 addresses the immediate issue by removing inline from the function declaration. However, the deeper issue is that any such inline ICACHE_RAM_ATTR function anywhere in the code could run into the same optimization.
This issue is meant to track a more thorough solution. Specifically:
A. retest inline ICACHE_RAM_ATTR Twi::reply() with gcc 9.x (PR #6294 )
B. If A still shows the iissue, look into disabling the specific optimization with -fdisable-ipa-fnsplit (flag isn't available in gcc 4.8.x)
C. If B doesn't work, document that inline ICACHE_RAM_ATTR is undefined behavior and can cause a crash.