Re: [WheelCommander] I2C comm failure with analog reads

[plskeggs@xxxxxxxxxxxxxxxx]

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
>