Re: [WheelCommander] I2C comm failure with analog reads

Milton Street <miltst@xxxxxxxxxxx> · Sun, 26 Jul 2009 11:36:05 -0500

It would appear that if you do _not_ send any movement command(s)... or, in other words as long as the WC PID routine(s) are not active... that then there is no problem with the I2C comm when polling the battery level (or any other analog input value).

If even just one  simple Velocity and Go! command are sent first and the a loop started after to poll any analog data... then eventually at some point the WC will lock up the I2C bus. When it does, the SCL line of the WC becomes locked low preventing any further I2C communications. The SDA line seems to   end up locked low also (although I am not 100% positive that it always ends up low).

I should also mention that the majority of the time (but, not always) the Green LED will also turn off when the WC locks up the I2C lines.

Since it appears that it is only the analog reads that are a problem, and since the ATMega processor does require a short period of time to complete an ADC read... there may be a conflict with the usage of a Timer for the ADC read while the PID routines are active (or, maybe a problem caused by the various interrupts overlapping).

As far as the programming language and MCU that I use on my end... that really should not be a problem since it is the WC that is locking the SCL line low. The I2C Master end can do nothing at all if its the slave that keeps holding the clock line low.

However, since you asked... I normally work with ZBasic using ZX-24a modules (which use an ATMega644 processor). I've also used a ZX-1280 which is really great if you need a lot of I/O lines or require the usage of many Timers.

You can find out more about ZBasic at: http://www.zbasic.net

A few years back I worked with BasicX but found it was far to limited (and had several flaws as well).

Hope this helps you track down the I2C problem in the WC firmware.

Regards,
Milton Street

----------------------------------------
> Date: Sun, 12 Jul 2009 18:41:31 -0700
> From: plskeggs@xxxxxxxxxxxxxxxx
> To: wheelcommander@xxxxxxxxxxxxxxxxx
> Subject: Re: [WheelCommander] I2C comm failure with analog reads
>
> Milton,
>
> Thank you for the detailed bug report. I'll investigate this as soon as I
> am back in the office on the 25th. Meanwhile, what kind of I2C master you
> are using? What processor, what programming language and version, etc.?
>
> It may be related to simply periodic polling of the analog inputs. Can
> you try simply polling the battery level without the movement commands?
>
> We do protect the access to analog inputs as well as digital inputs and
> outputs using semaphores, so that the command handler task needs to take
> ownership of the resource before accessing it; if another task has
> ownership, the handling of the command is deferred until the resource is
> available.
>
> Likewise, if the command handler task owns a semaphore while another task
> needs the resource, its access is deferred.
>
> Anyway, on an infrequent basis, the clock stretching will be much longer
> than normal (but still not exceeding a few milliseconds, IIRC).
>
> -Pete
>
>
>> First, thanks for your response about working on the mode problem with the
>> Wizard and also the Red LED glitch in the firmware. Now, I've got (yet)
>> another firmware bug for you to figure out.
>>
>> In my testing, I've found that if it issue just a simple movement command
>> (just tell it a speed and go), and then try to repeatedly poll the battery
>> levels (or any other analog pin reading) at say once a second...
>> eventually (usually within 20 seconds or so) the I2C communications of the
>> WC just totally lock up. Even if I poll for readings further apart like
>> every 3 seconds or more it still eventually will lock up.
>>
>> The WC ends up stuck pulling both I2C lines low. Since the SCL line is
>> being held low, it would appear that it's stuck "clock stretching". This
>> in turn causes my own MCU to lock up waiting for the I2C transfer to
>> complete.
>>
>> Meanwhile, the bot servos continue running forward with the bot in an
>> (unsafe) run away condition without being able to regain control via I2C.
>>
>> I do not know if this problem is strictly limited to only doing analog pin
>> data reads. Nor do I know if it's strictly the I2C comm that locks up in
>> this situation because I have never tried testing analog pin reads with a
>> Serial connection.
>>
>> I'm guessing that since the analog values are 32 bits that somehow with
>> that larger number of bits to transfer that some kind of clash is
>> occurring between a timer in the WC CPU being used for something else
>> while the I2C routine is also trying to use it.
>>
>> Hopefully you can track down this problem and get it fixed also in the
>> next firmware release.
>>
>> Regards,
>> Milt
>>
>>
>> _________________________________________________________________
>> Lauren found her dream laptop. Find the PC that’s right for you.
>> http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290
>> _______________________________________________
>> WheelCommander mailing list
>> WheelCommander@xxxxxxxxxxxxxxxxx
>> http://list.nubotics.com/mailman/listinfo/wheelcommander
>> Nubotics Website:
>> http://www.nubotics.com
>>
>
>
> _______________________________________________
> WheelCommander mailing list
> WheelCommander@xxxxxxxxxxxxxxxxx
> http://list.nubotics.com/mailman/listinfo/wheelcommander
> Nubotics Website:
> http://www.nubotics.com

_________________________________________________________________
Windows Live™ Hotmail®: Search, add, and share the web’s latest sports videos. Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_videos_072009&cat=sports