Hi, folks. First post here. I recently set up a Spark Core on our office fridge to post HipChat messages. I am using the ported libraries found here:
For the record, it works quite well. However…I am seeing periodic “freezes” of the display. The behavior is that the spark will still be online, will still respond to API function() calls, still seems to be doing it’s job. However, the display itself ends up frozen in a past state. My theory is that due to a timeout or due to a jostle (it’s mounted to the fridge door) it is losing intermittent connectivity to the I2C bus. I’m not sure how to detect the health of the I2C bus to verify this.
If my theory is correct, rerunning the “begin” function would reinitialize the SSD1306 and reestablish the connection. I could do this hourly, but this seems kludgy. I could do this on every refresh, but it seems wasteful and causes a flash of the display.
Am I missing something that I could be doing to enable a long-running connection to this LCD display? Because it appears that no wire.end() or display.end() exists in the official libraries, it is not currently possible to say (1) initialize the display (2) paint the display (3) terminate the connection entirely.
Any thoughts here? I’m wondering if there is a way to solve this without hacking the existing SSD1306 library or putting a hourly loop to kick the Spark in the pants to get it to reconnect. I’d love to hear that I’m completely misinformed about this behavior.
The first obvious test would be to remove it from the fridge door and place it on your desk top stare t at the setup to ensure that the jostle isn’t causing an issue.
It probably shouldn’t be caused by that though…
Sounds like the polling of messages from Hipchat isn’t causing issues for you and only the display “hung” up
I also see i2c reliability has dropped in recent firmware. I have same hardware running since spring. It works OK on firmware built in july, but i2c display often disconnects when compiled with recent one.
I see that there were some I2C polling changes added to firmware v0.3.4 that was released sometime around October 21. Since I have rebuilt my project and flashed since then, I should be taking advantage of this fix. Yet, I am still seeing the display periodically (after a few hours in my case) become unresponsive.
@ryotsuke, it seems the enableDMAMode() function is not in the documentation just yet and there may be a reason (!). Nonetheless, I2C DMA may be enabled as follows:
I tried today with DMA mode enabled and disabled. The result was the same. After a few hours, the display would become unresponsive even though the spark itself thought everything was fine.
I’m happy to try any other tweaks or enhanced logging if my situation could shed any light on the troubleshooting process. I’m wondering if I would have achieved better stability if I had purchased the SPI version of this display.
Thanks for all the info. Spark’s community was one of the reasons I purchased into this ecosystem instead of a few others.
@peekay123 Were you able to reproduce any strange I2C connection losses using your display? I would be happy to share wiring diagrams and/or code/libraries if that would be helpful. If the problem is known and a fix is underway, that’s cool. I’m mainly curious if this issue is stalled and I need to look for an alternative for my application. Thanks
Im having similar i2c issues where the i2c bus will just hang after a random amount of time. My i2c devices are HTU21D, K30 and Atlas EVO modules. I also have a 1-wire device, that keeps working just fine when the i2c quits. Will be tracking this issue closely.
