drewsum
commented
4 years ago This is in progress. I've minimized the likelihood of the issue arising during normal operation by having I2C sensors only be polled during telemetry serial stream. I also set the I2C1 Master Interrupt to IPL7 in the hopes that this was caused by strange timing issues with the master interrupt being interrupted by higher priority interrupts. Seems promising so far. I also gutted all of the 10-bit I2C support code in the I2C master driver since this is never used. This should hopefully speed up execution of the master ISR, since it's really long. Here'es hoping this will fix this!
An issue with I2C that has plagued the electronic calendar is appearing on this board as well. This is making me think it's either interrupt related or has something to do with storing all of your telemetry in a C structure. Regardless, the CPU gets hung up every once in a while. Since moving the WDT clearing function to
main(), rather than "stall", the CPU is reset by the WDT. This confirms that when this stalling issue happens, the CPU core is not returning back to IPL level 0, or back to main. If I comment out the continuous I2C polling for all of the telemetry sensors, this issue disappears.Figure this out and apply it to electronic_calendar too.
May want to switch to a purely-blocking implementation of I2C instead of interrupt driven, since you're blocking anyway. If shit is still completely broken, consider using a bit bang implementation.
I2C has a lot tied to it on this board and it would suck to throw in the towel on this. At the very least, leave the IO expander/RTC nonsense but get rid of polling telemetry sensors. This really sucks to see appear on this project as well.