Bitcraze Forums

Getting closer: I need to use I2C3_DEV instead of I2C2 (CF 1.0). Now the firmware compiles without warnings, finally. Furthermore, I initialized I2C3_DEV a second time by mistake although it has already been initialized in imu_cf2.c. Fixed that.

The CF 2.0 can be found and connected with the PC Client, but telemetry data is a mess (weird values drifting without any evident correlation to the copter's movement, just as the ASL) and the artifical horizon doesn't respond at all. The console repeatedly outputs:
What does that mean, is there any error code information available? The copter works well with the standard firmware by the way.

Still testing...
Changed the code for the sonar sensor to I2C1_DEV, but without initializing the bus. This is already done at system start for accessing the EEPROM.

After startup, the red heart beat flashes two times before it stays dark completely. Only the two blue LEDs are constantly switched on. Can't figure out why the copter gets blocked. No connection possible.

Is there any documentation about what I2C port to use for connecting peripheral devices? The documentation is still lacking these simple but important facts.

I would be grateful for every hint.

After startup, the red heart beat flashes two times before it stays dark completely. Only the two blue LEDs are constantly switched on. Can't figure out why the copter gets blocked. No connection possible.

My guess is that the code runs into a hard fault. Can you push your code in your repository so I can try to debug it?

Is there any documentation about what I2C port to use for connecting peripheral devices? The documentation is still lacking these simple but important facts.

Not yet really but it is on its way . So for the moment one have to look at the pinout, schematics and the STM32F405 documentation. I uploaded a image of the mapping until we have made it more clear.
The expansion port i2c is on I2C1 (same as eeprom).

Hey tobias,

thanks for jumping in. Here you have my sonar-cf2 branch holding the CF 2.0 port of my original CF 1.0 sonar implementation (that you know already... ):

https://github.com/alexriegel/crazyflie ... /sonar-cf2

Pushed the change to I2C port I2C1_DEV some minutes ago.

OK, I did some SWD debugging and I found a bug. The ST I2C library (CPAL) get stuck in a timeout. This happens when there isn't anything to communicate but works if things run as it should. So I'm thinking you aren't getting any answer from the sonar sensor? I tested just changing the MB1242 driver to talk to the eeprom instead (setting address 0x50) and then the code runs. Are you able to check that the MB1242 sensor answers, with an oscilloscope or similar?

tobias wrote:OK, I did some SWD debugging and I found a bug. The ST I2C library (CPAL) get stuck in a timeout. This happens when there isn't anything to communicate but works if things run as it should. So I'm thinking you aren't getting any answer from the sonar sensor? I tested just changing the MB1242 driver to talk to the eeprom instead (setting address 0x50) and then the code runs. Are you able to check that the MB1242 sensor answers, with an oscilloscope or similar?

Damn, that was quick. I'll fire up my oscilloscope as soon as possible.

Do you think the reason might be that the I2C1 is running in fast mode (400 kHz) but the sensor only supports standard mode (100 kHz)? If I only address the sensor every 80 ms (as stated in the datasheet for near 'realtime' applications) and return a buffered range if addressed faster (500 Hz main loop), this should not be a problem, should it?

You could always try to run it slower to see if it changes anything. I found this in the datasheet:

Pin 5-SCL (I2C Clock): This is the clock line for I2C communications. These sensors support I2C clock frequencies up
to 400kHz provided clock stretching is supported by the master device. Without clock stretching the devices can run at
speeds up to 50kHz.

I'm pretty sure the STM32F4 supports clock stretching but maybe the bug could be triggered here. Try switching the i2c clock frequency to 50KHz and see if it changes anything.

tobias wrote:You could always try to run it slower to see if it changes anything. I found this in the datasheet:

Pin 5-SCL (I2C Clock): This is the clock line for I2C communications. These sensors support I2C clock frequencies up
to 400kHz provided clock stretching is supported by the master device. Without clock stretching the devices can run at
speeds up to 50kHz.

I'm pretty sure the STM32F4 supports clock stretching but maybe the bug could be triggered here. Try switching the i2c clock frequency to 50KHz and see if it changes anything.

I can remember that I changed the clock for the sonar's I2C bus to 100 kHz on the CF 1.0 version of my code.
But since the CF 2.0 has its EEPROM on the same I2C1_DEV bus, I don't know whether this is a good idea to set the whole bus to 100 kHz. I am going to test that out... although I thought there has to be a 'cleaner' way. Thanks again, tobias.

I set the I2C1 bus (for EEPROM and sonar) to 100 kHz and the copter starts up normally. The LEDs are acting as the are supposed to and I get a stable connection. Pushed the changes to my repo.

But: The telemetry data in the PC Client is still showing weird values (e.g. the ASL). Neither the data fields nor the artifial horizon react to the copter's movement in my hands:
This is the console output:

Well to steps forward and one back .

I'm thinking there is still something wrong with the i2c buss then. If you flash the release software I guess everything is working as it should (to rule out cfclient issue)?