Bitcraze Forums

arnaud wrote:This sounds like it is crashing somewhere when reading the sensor. It could help to look at the I2C lines to see if there is any communication going on. Also lighting up an LED just before reading a range value and lighting off just after will tell you if it crashes in this part of the code or somewhere else. Also a random though: try to increase the stack size of the task that runs your code. Having a stack overflow there it typically the kind of thing that would crash the copter.

Is it possible to send the boolean return values of the I2C function calls via the log framework to the client? Can't find the right datatype to create a LOG_GROUP.

Your help is very appreciated, thank you.

Since we run on a little endian machine you are safe setting the log in unsigned 8 bits, it will send 1 or 0 depending of the bool value. I would guess bool is 32bit wide but I'm not sure.

arnaud wrote:Since we run on a little endian machine you are safe setting the log in unsigned 8 bits, it will send 1 or 0 depending of the bool value. I would guess bool is 32bit wide but I'm not sure.

Ok, I will try to track down the issue with the help of your input.

tobias,

I wrote some dirty debug code using the on-board LEDs and found out that neither i2cdevWriteByte nor i2cdevReadByte return TRUE, i.e. these functions fail.

After stepping through the I2C interface with brain 1.0 (rooting address and data bytes through the function calls, looking how they are used/modified), I assume I2C_Master_BufferWrite is timing out. Can't find an interrupt handler for I2C2 in i2croutines.c, maybe that's the reason? Can you verify that or am I wrong?

Thanks and good night.

Hi Alex!

Are you sure you are using the latest code from the repo? Here is the code for the I2C2 interrupt handler.

tobias wrote:Hi Alex!

Are you sure you are using the latest code from the repo? Here is the code for the I2C2 interrupt handler.

Yes, I am absolutely sure, double-checked that again. Both master branches are identical. Overlooked that interrupt handler for I2C2 before.

Some days ago, I managed to eliminate the hang-up on startup (as described above). The clock divider for addressing the MB1242 was set to high which caused the copter to hang after startup. I reduced the loop rate for sonar to 10 Hz and tada: the CF starts up as expected. Nevertheless, I can't send or read any data via I2C2 successfully, the I2C functions simply fail.

The datasheet states 100 kHz as the highest possible I2C bus speed for the MB1242. The CF's I2C bus runs at 400 kHz, therefore I changed i2croutines.c so that I2C2 gets initialized with 100 kHz - separately from I2C1. No change, no answer from the sonar.

The more I look at the code, the more I have a suspicion that my physical breadboard circuit is the problem... Can't find a wiring error, though...

Would someone tell me how to connect a LED to the sensor's status pin in order to visualize its state? My 3 mm LEDs need 2 mA of current. Can I just wire them between the status pin and GND?

Here's a quick status update:

Did some measurements with a multimeter. I assume that the sensor has a defect since it consumes 0 mA during operation. According to the datasheet it should have an idle current consumption of around 2.7 mA, which obviously isn't the case. I sent it back to the vendor hoping to get a replacement.

In the meantime I designed a mount for the sensor. The plan is to get a 3d print using Selective Laser Sintering from Trinckle. Made from PA, it weighs about 1.2 grams. Later on there will be a support for the step-up regulator NCP1402 providing the 3.3 V for the sensor.

Thanks to the dedicated help of the watterott.com service team, we narrowed down the problem:

• The sensor itsself is working fine.
• The wiring on my breadboard is correct, too. (the pictures in my CF gallery are outdated)
• My code for requesting and reading measurements from the sensor is ok, including the I2C addresses.
• The I2C2 clock is set to 100 kHz, see my commit 9ecedfc.

But: The implementation of the I2C2 interface in nvic.c is most likely incomplete. The call to the corresponding interrupt handler is missing. I opened an issue:

https://github.com/bitcraze/crazyflie-f ... /issues/27

Could somebody familiar with the interrupt and I2C internals have a look at it?

Come on, guys, I'm really stuck with this project, did someone have a look at it?
Has someone ever managed to communicate with an external I2C sensor via the expansion port?

Sorry for asking with importunity but it's really frustrating to cope with basic things like this for weeks.

In the next few days I'll have a look at SDA/SCL on I2C2 with an oscilloscope...

We have been insanely busy, sorry for not replying.

We have had the I2C2 bus working with other sensors but we have so many clones of the FW that I don't know which one it is. We will do our best to try and solve this today.
/Tobias