Re: [Paparazzi-devel] possible I2C problems halting the main loop, sys_mon module and telemetry settings

[Christophe De Wagter]

Dear Simon,

The I2C problem is a real-time programming (or multi-thread or race-condition) problem on top of electrical difficulties. This pretty much means "that some combinations seem to work while others do not." One combination known not to work is aspirin+mikrocopter controllers. But mikrocopter controller only + booz imu does work. And aspirin+astec also works. (please do not ask me why)

I've continued the work on the new driver (stm_i2c branch) and might get a little help from Piotr for the final step: the watchdog to solve the remaining problems that will otherwise never disappear. But this issue is so hard that making promises as to when it is ready. Any real-time programming expert (that understands the fact that reading registers can also alter their content and that the content might have changed by the time the cpu processes the actual comparison)

Besides this, the stm can have many pins re-organized as PWM outputs. 

Question: has anyone ever found ultra-miniature CAN-controller board that are cheap/small enough to put next to each motor? Like a Atmega+Can chip?

On Thursday, March 8, 2012, Simon Wilks wrote:

I am kinda stuck at the moment as I2C seems unreliable on the STM32 boards and this is why I am considering all options including dropping I2C and going for PWM for my octo, if only I could find a way of getting 8 PWM outputs (see my other post).

Another question on I2C: has anyone been having issues on non-MK controllers or is it just the MK causing weird problems? If I can't go the PWM track I might consider selling the MK octo powerboard and getting the Herkules II with it's own, what I would hope better, I2C implementation. I could still use it for PWM output which is not an option on the MK controllers as they are known to have crap PWM implementation. Of course this is only if the problem is not due to a the Paparazzi I2C implementation.

@Craig: I had problems with the Lisa/L (worse than what I was experiencing on the Lisa/M) and the problems seemed to go away when I deactivated the Aspirin IMU. So this might fit with your theory on interrupt issues.

Simon

On Sun, Mar 4, 2012 at 11:04 PM, Simon Wilks <address@hidden> wrote:

On Sat, Mar 3, 2012 at 8:55 PM, Felix Ruess <address@hidden> wrote:

Hi Simon,

I don't think that would help in the case where an I2C slave doesn't release the SCL line anymore...

The board uses an LTBBC (LTC4304) Hot Swappable 2-Wire Bus Buffer with Stuck Bus Recovery chip for each I2C slave and according to the datasheet (http://cds.linear.com/docs/Datasheet/4304fa.pdf) it provides "Automatic Disconnect of SDA/SCL Lines when Bus is Stuck Low for ≥30ms". 

Of course an isolator is only of use if you are using at very least a hexa. 

 

the only way to resolve this (that I know of) is to toggle the line until the slave releases it again.

Cheers, Felix

On Wed, Feb 22, 2012 at 9:26 PM, Simon Wilks <address@hidden> wrote:

Would an i2c isolator help get around this problem? I have one but didn't want to have to mod the distributor board (cutting C/D tracks) unless I had to. This sort of issue is probably going to stop me flying the octo so I would reconsider if you think it might help.

Simon

On Wed, Feb 22, 2012 at 11:56 AM, Felix Ruess <address@hidden> wrote:

I merge the pull request from Andre (thx!) into master (and dev, 4.0_beta).

So this should fix the main loop not hanging anymore, but as Andre said the bus will still be stuck (at least in most cases) and the mkk controllers won't work.

Cheers, Felix

On Wed, Feb 22, 2012 at 1:12 PM, Felix Ruess <address@hidden> wrote:

Hi again Andre,

if your testing goes well, could you plz make a pull request with the timeout counter added. It will at least solve part of the issue in the meantime.

That would be great!

Cheers, Felix

On Tue, Feb 21, 2012 at 8:19 PM, Felix Ruess <address@hidden> wrote:

Hi Andre,

I added a similar timeout counter for testing a while ago as well, of course I then couldn't reproduce the problem anymore so I couldn't really test it :-(

Haven't really had time to dig into the issue again since, so your help is very much appreciated!

The question also is how much effort to put into fixing (writing workarounds) for the current driver... since the new driver is apparently basically done..

@Christophe, any comments on this?

Cheers, Felix

On Tue, Feb 21, 2012 at 8:06 PM, Andre Devitt <address@hidden> wrote:

I have recently run into this issue and am in the process of testing a fix.

Basically what can happen is that if a slave holds SDA low t

-- 
-Christophe