I2C lockup issue

I recently got a Netduino Plus 2 and I've been trying to figure out this strange locking issue with the I2C bus on this device.

In my first configuration I have 10k pullups on my SCL and SDA.  In this case I see a single start sequence as the device resets and then the bus goes high forever.  I detected no falling edges on SCL or SDA.

Then I tried 1k pullups and things worked fine,  I still get the odd start pulse when the device is reset but everything comes back alive after boot is completed, [ Blue LED goes out ]

I decided to try the 10k again just for kicks; when I powered up it worked.  That's weird.  So I changed my code to just change the values of the data being sent and then I was back to the locking state.  Put the 1k resistors back in and things magically worked again.

The max Rp for 400 kHz is 8k at roughly 50 pf bus loading and 20k for 100 kHz.  I ran this at 100 kHz and 400 kHz with the same results.  So 10k should not have caused a problem for my 100 kHz test and it should have been just barely working at 400 kHz, with one load it should be less than 50 pf bus loading, but working none the less and it did; until I reprogrammed it.

I suppose this could be related to the errata for this part, Errata 2.3.2, but that is for a stop and I really don't have any way of knowing.

This is really odd behavior but I can see this on my o-scope.  Maybe this is a known issue that has already been discussed here but I though I'd throw my 2 cents at it.

Hello Yogotie,

have you seen this article ?

http://www.dsscircui...-resistors.html

I have some problems with the I2C, mabey i should try my scope and change the pull-up resistors a bit.

I have some hardware running on the old plus, ok.

But get  no response on the netduino plus 2.

I think it could also be a code thing.

Also did try update every thing also the 4.2.2.2 firmware.

Edited by JohanV, 08 February 2013 - 04:04 PM.

That is a cool plot of the various pullup values on the bus.

I just tried this again with 4.2.2.2 and there is no change.  In my test I have my code in an infinate loop doing the same I2C transaction so I should see something, a start or stop or runt SCL.  Instead I see nothing, I have my scope set to trigger on any edge and I get no triggers.  All I get is a bogus start as the part is resetting.

So the question is why do I get nothing with 10k pullups?  Why does it work when I change from 1k to 10k and then stop working when I reprogram? Why is it not locking up when I use 1k?  Why do I see nothing on the bus after the timeout period of 1 sec with 10k?

We seem to have a similar problem, with the I2C working sometimes, and sometimes not. Eventually, we would like to connect a RTC and a LCD, but whenever the hardware setup is changed a little bit (i.e. pull-ups), it seems to impact the stability in a way that is puzzling. We have installed the latest firmware / frameworks. So, we are also very interested in getting answers to yogotie's questions.

Looking at the work around for Errata 2.3.2 lead me to look at the I2C registers I2C_CR1 (SWRST bit) and I2C_SR2 (BUSY bit) in the reference manual.

This is the note from the reference manual, 25.6.1 pg 724, for SWRST in I2C_CR1

The BUSY bit is set when SCL or SDA goes low, start is not required, and will only be cleared on a stop condition.  Weaker pullups means that it is much more likely for glitches to occur on SCL or SDA and will be totally dependent upon your specific configuration.

In order to deal with the issue stated in the note for SWRST and the Errata it is necessary to have the ability to set / clear SWRST or have some mechanism that will reset the I2C peripheral from the application, C# side.  The low level firmware cannot automatically handle this case because there is no way for it to know the characteristics of the system it is in.

So my question is how do I do that?

My netduino plus 2 still have a zero on the I2C execute. ( could this be a lock up as well ? )

also used different pullups, but no luck.

It maybe possible that is what is happening, at the moment that is my most likely suspect.  Since there is a start condition on the bus when it beings booting I am suspecting that in some cases, such as mine [ with 10k pullups ], the I2C controller is marking the bus as busy when this happens.  But without visibility into the registers I cannot know for certain.

I'm going to buy a debugger so I can get some visibility into what is going on.

Hi Yogotie,

I have about a similar problem mabey. But i have a 4 channel 100Mhz scope, with USB connection.

This weekend i have some time do check this.

i have been thinking it has some thing to do with the I2C busy, or not sending the right start or stop command on the bus.

thanks

I was able fix my problem by modifying the firmware from the source that is available for download, I think it is 4.2.2.0, and made some simple modifications.  I do not have my debugger yet so I cannot say what the exact state of the I2C peripheral was however I have gone through the steps of my previous debugging to verify that this does fix the issue that I was seeing.

In DeviceCodeTargetsNativeSTM32DeviceCodeSTM32_I2CSTM32_i2c_functions.cpp

function : I2C_Internal_Initialize()

I added :

        I2Cx->CR1 = I2C_CR1_SWRST;

Hi Yogotie,

very intresting, i have seen this similar problem on my ND2+ it at booting pulled down.

and when the program runs, it's not doing any thing any more.

i have a 4 channel 100 mhz scope. and on the old ND+ it's running smooth.

it looks the same. problem, could you some how send me this modified firmware ? to my private email or so ?

thanks

I just got my debugger and have been able to verify that when the I2C bus locks up the busy bit is set.

Your custom firmware works for me.. THANK YOU... you are right the CLOCK line is locking up....  YOU ARE GENIUS... Chris Walker please have look....

Thanks, I'm glad that it worked for you.

Would it be possible for someone to create and share a modified 4.3 firmware with this fix? I believe I have the same problem with one of my I2C devices, but I'm not comfortable creating my own firmware (yet).

Perhaps Chris could share a "4.3 experimental I2C fix" firmware version?

Hey Frode,

I'm working on it right now. I've got the porting kit, latest firmware, have already updated/injected the two lines of code, and going to attempting to compile it right now...it might take me some time to figure it out...

If I can get something compile and upload to the board, I'll post it.

Great! Hope you get it working!

Chris, any chance this will make it into a firmware update?

The OLED display I'm using with I2C is really unstable when I use the Netduino, but if I connect it to an Arduino Leonardo instead it works just fine. In another forumthread I see that gismo and some others are trying to compile a custom firmware, but I think they've reached a deadend. There is also the other I2C debugging thread which is related to this one.

It would be great if SecretLabs issued an experimental firmware version so that we can test the fix Yogotie figured out.

Has this been fixed in the latest firmware? (Or was this a problem with specific peripherals?)