Just ignore BERR? Do you mean that you can disable the hardware detection of BERR? That would be awesome! Because right now after a BERR the driver MUST manually stop the transaction and start the next one or restart it and not forget to re-enable the master mode as BERR automatically puts the I2C in slave mode. So it depends of what you mean with ignore.
On Jun 19, 2012 4:08 PM, "Xavier RIVIERE" <address@hidden> wrote:
Hi Christophe,
You are right. By the way, I checked the board (R33 and R34
soldering), and it didn't change anything. The cable is as short as
possible, and I checked the connector
According to the datasheet, the software can just ignore the BERR
error, and so, I tested this way. No change.
The program stop I2C2 after a while, for an unknown reason...
Le 19/06/2012 11:41, Christophe De Wagter a écrit :
Dear Xavier,
I'm very sorry for your trouble. But thank you for the
debugging information you provided.
First: what is happening:
On startup paparazzi starts reading the sensor before it is
ready, which yields the acknowledge_failure. That is a normal
error and well captured by the i2c hardware of the STM.
An arbitration_lost error however means that the stm32
microcontroller noticed a short-circuit on the data or clock
lines. This can happen in multi-master setups (thereby the name:
master-arbitration). But it can also happen when your circuit is
electrically not perfect. In this case, the pull-up resistors
need to evacuate all electric charge in the very capacitance
sensitive I2C lines. Too small resistors and that happens too
slowly. Even worse, in the presence of interference you need
only a relatively small EMI field to induce voltages on the I2C
wires. So the processor requests a bit of 1, then measures the
result and notices that 100 nanoseconds later it is still zero,
and decides that there must be someone else jamming the bus. On
Lisa-L, the I2C bus goes from one board to another, which is not
nice. Keep wires short and away from interference. In any case,
reducing these 2 hardware problems is always important.
Now more interesting is the unexpected_event.
That is more likely to be a software driver error. I do
not have the given hardware combination to reproduce the error
but will try using a Lisa-M and manually tamper with the
lines...
-Christophe
On Tue, Jun 19, 2012 at 11:11 AM,
Xavier RIVIERE <address@hidden>
wrote:
A little more about the error, from the message :
- On start, acknowledge_failure is rising, but never more
than 50 errors. Well, it's annoying but not blocking
- At one time, there is an arbitration_lost error. Just one.
- After that, unexpected_event are rising and rising and
rising and rising
So arbitration_lost is the blocking error... I have to say
more ? ;)
Xavier
Le 19/06/2012 10:12, Xavier RIVIERE a écrit :
>> first a clarification: the new I2C driver is
not the default yet for a reason.. it is still missing
watchdogs.
Ok. But... with the old one, nothing works... The
board stay idle, without even the sys_time_led
>> Also the AHRS_ALIGNER_LED is supposed to
blink until the aligner is locked (gyro bias
initialized) and stay on after that...
That's interesting. It means that in fact, I never saw
the system working, 'cause I never saw the aligner
locked
Here is my symptom :
- On start, LED blink... value change on "message"...
I see I2C exchange with an osciloscope
- Then, the AHRS_ALIGNER_LED stop to blink... value
don't update... and there is no I2C exchange anymore
>> Only the gyro and mag measurements are not
updated anymore?
Yes... and that's interesting too : the baro is still
working... and it's on the I2C2 too... so the problem
don't come from the I2C routine, as i2csubmit function
is still working.
Well, in fact, I have a toolchain with Eclipse, so I'm
investigating by my side. On my personnal branch, the
mag is no working, but only will help from the
watchdog, and with the old driver. I will investigate
on AHRS today ;)
>> I just added a filed to the I2C_ERRORS
message to indicate for wich bus number the errors are
reported...
>> Would probably be helpful to post the
I2C_ERRORS messages you get (after git pull &&
make).
So far, I have :
- 17 Acknowledge_failure_cnt
- 1 Arbitration_lost
- 5860 Unexpected_event
- Bus number 2
Bus one is lost too, but there is only
Acknoledge_failure. It's strange, as I have MKK
actuators connect.
>> I'm not sure if one of the devs actually has
that exact combination...