What LCD exactly are you using?
I’m using a Digole OLED in I2C mode with zero issues.
Good to know the reset stuff is working at least. @BDub
FYI - I have more runs now - looks like this will help about 30% of the time.The rest of the time, nothing brings it back (including unpowering the LCD).
I feel so bad for the little board, trying to work so hard 
Ken
FYI I tried my DS1307 code on the Spark Core and Arduino… and they both run at 100kHz. The Arduino allows a tiny bit of delay between bytes, but the Spark Core is super tight… not idle bus time. I don’t think that’s bad though. In fact, with the 10k pull up resistors, the Spark has much less capacitance on it’s pins and the resulting waveform is much more rectangular than the arduino. Both work though.
I looked over the library port again, and I don’t see anything obviously wrong with it. I didn’t really change that much that would affect it either.
I think you’d need a logic analyzer to get this figured out.
How long does it take before it goes all Predator and stuff?
Hey @timb!
This is the LCD - RGB backlight negative LCD 16x2 and this is the I2C controller.
I am goign to put together my redundant kit. Maybe the I2C backpack or the LCD themselves are hosed.
Ken
@bdub - it varies for sure. Sometimes 30 seconds, sometimes 5, sometimes 300.
Let’s see how my redundant one works. I’ll let you know in 20 mins or so!
Ken
Well… there good news and bad news.
- Good news! I didn’t fry anything putting it together!
- Bad news… I didn’t fry anything putting it together! So this is definitely a real problem.
Ken
@bdub - I soldered the SPI jumper, and re-wired… but that gist has a bunch of HTML encoding in it ( > and the like ). I am stripping it out but the line breaks are also funky.
Can you put up a version that is not munged when it’s convenient?
Ken
Wow that is some shizzle. I guess I won’t be using http://prettyprinter.de/ anymore… at some point I ran it through there, and then through the arduino IDE auto format. Guess I’ll just fix it up by hand next time.
@bdub - Thanks for putting the time in. Unfortunately the moment that sketch is send down the Core locks up, and requires a full factory reset and re-configuration… the breathing light stops, the little blue on-board LED by the USB comes on, and it’s dead.
I’ll play with it more in a few hours 
Thanks again!
Ken
Just to update anyone watching - no luck.
- I backed away from SPI as everytime I used that library I had to factory re-set the core
- The I2C code above still works with the updated Spark firmware that fixes the I2C addressing bug, but you now need to use the “real” I2C addresses
- Sadly, my LCD’s still corrupt after a seemingly random amount of time - so there is still some deep oddities with I2C on the Core.
- I have now tried two LCD sets, on two Cores. Both LCD’s work perfectly on an Arduino UNO
Thanks for all the help folks… if / when I get it working I will make sure I update this thread.
Ken
cc @BDub
2 Likes
My backlog is stacking up, but I have a 74HC595 to try and debug the SPI lib this weekend hopefully.
@BDub - no worries mate, I’ll keep looking into it as I get more familiar with the platform.
Ken
Guys,
I may have had a similar problem with implementing the BMP085 pressure / temp sensor. It uses I2C and when I used the basic library floating round the net I would get a few samples out of the device and my code would lock up on the I2C read. I studied the code and found that each time in my loop of getting & displaying the pressure, temp, altitude, it sampled the BMP 7 times quickly as fast as possible. I have since changed the code to only sample the BMP once every 1.5s. Now the code runs overnight, before it only ran for 6-15mins. I suspect the I2C library can’t handle heavy usage at this time. Forgive me @BDub 
Yes, introducing at least a 15ms delay between a Wire.endTransmission and begin event will greatly improve the stability of I2C.
Keep in mind, on the Core’s I2C implementation transmission doesn’t take place until you call end, so if it goes into the next begin statement too quickly the buffer is getting overwritten.
Try adding a delay and see if that helps.
Thanks, I will add a delay after the Wire.endTransmission to allow for the data to get written out and report back.
I did ad a little bit of delay, and it helped… but eventually it locked up anyway.
Ken
So I checked this today - given that we have new firmware. It is somewhat more stable, but eventually it does still lock up and die.
https://gist.github.com/soulhuntre/8674179
Ken
Cannot get it work with this backplane…
and have no idea how to fix it… Does not depend on pull-up resistors…
SPI addres is 0x27…
Arduino-Code from http://arduino-info.wikispaces.com/LCD-Blue-I2C#v1 runs perfect on my nano.
Can anybody help?