Initialization failed with two decks

Firmware/software/electronics/mechanics
Post Reply
unario
Beginner
Posts: 8
Joined: Fri Jan 12, 2018 11:25 pm

Initialization failed with two decks

Post by unario » Tue Feb 06, 2018 4:39 pm

Hi forum,

I have made my own deck which communicates with the board using the I2C interface. The crazyflie also connects to a flow deck at the same time.

But often (not always), when I turn on the board, the drone cannot finish the initialization. The board is stuck at a point where the two blue LEDs are lit on, but the motors are not tested, there is no test sound, and the red LED is not blinking. So I could connect to the board using cfclient. Sometimes, the initialization is totally fine and the board is able to read data from my own deck.

If I remove the flow deck and use only my own deck while using the same firmware, the initialization is always fine.

The I2C addresses of devices on my deck are different from the VL53L0X.

I suspected the I2C double initialization, but it seems not the case. Getting rid of I2C initialization in my own deck driver did not solve the problem.

I have run out of ideas why the above is happening. Any thoughts on the reason or ways to debug this issue are greatly appreciated.

Thanks!

arnaud
Bitcraze
Posts: 1609
Joined: Tue Feb 06, 2007 12:36 pm

Re: Initialization failed with two decks

Post by arnaud » Wed Feb 07, 2018 1:37 pm

Hi,

If you connect the Crazyflie with the client and look at the console tab, can you see where the print-out stops? You can also compile the firmware with DEBUG=1 to get a bit more prints, might give a clue about where it stops.

unario
Beginner
Posts: 8
Joined: Fri Jan 12, 2018 11:25 pm

Re: Initialization failed with two decks

Post by unario » Wed Feb 07, 2018 8:44 pm

Hi @arnaud,

After some debug print, I found that the execution got stuck here in the function vl53l0xGetSpadInfo:

Code: Select all

  startTimeout();

  uint8_t val = 0x00;

  while (val == 0x00) {
    i2cdevReadByte(dev->I2Cx, dev->devAddr, 0x83, &val);
    if (checkTimeoutExpired()) { return false; }
  };
Any suggestions? Thanks!

arnaud
Bitcraze
Posts: 1609
Joined: Tue Feb 06, 2007 12:36 pm

Re: Initialization failed with two decks

Post by arnaud » Thu Feb 08, 2018 8:12 am

If you run a stock firmware (like the latest release), and you start the Crazyflie with both decks do you see the same problem?

It looks like your deck is physically affecting the I2C bus, are you connecting long-ish wires or capacitors to the bus?

unario
Beginner
Posts: 8
Joined: Fri Jan 12, 2018 11:25 pm

Re: Initialization failed with two decks

Post by unario » Thu Feb 08, 2018 6:11 pm

With the latest firmware release, the initialization works fine with the two decks (flow deck and my own). So I guess it was a software issue instead of hardware, but I am not sure.

I have a PCB and I don't think there are long wires. I am connecting the bus to an I2C multiplexer (PCA9540B) and I also connect two 10k pull-up resistors to SDA and SCL.

arnaud
Bitcraze
Posts: 1609
Joined: Tue Feb 06, 2007 12:36 pm

Re: Initialization failed with two decks

Post by arnaud » Fri Feb 09, 2018 9:41 am

There is already pull-ups in the Crazyflie since this I2C bus is used for the EEPROM in the Crazyflie. So you should avoid adding extra pull-ups to the bus.

However I agree with you that it looks software. Have you tried to initialize your chip after the system is initialized? So, initializing it in a task after systemWaitStart(). If there is a problem of address collision or task synchronization with the I2C driver, this could make a difference.

Just a though: the vl53 driver is changing the address of the VL53's at startup, this is because all VL53 starts with the same address and the only way to have more than one is to switch them ON one by one and to change their addresses. This is what we do with our multi-ranger prototype decks, we have an I2C GPIO chip to enable the sensor one by one. The VL53 will end-up on addresses 0b0101001+n with n being from 1 to the number of vl53 initialized.

unario
Beginner
Posts: 8
Joined: Fri Jan 12, 2018 11:25 pm

Re: Initialization failed with two decks

Post by unario » Fri Feb 09, 2018 4:15 pm

OK, then I think it is an I2C address conflict. The address of the sensors I am using is just 0x29 (0b0101001) and the address is unchangeable.

I checked the datasheet of VL53 and it says the address is 0x52, so I did not suspect address conflict.

I notice that the VL53 will initialize using the default address 0x29. And I think that is the reason.

Code: Select all

dev->devAddr = VL53L0X_DEFAULT_ADDRESS;
Is there a way to change the default address of VL53?

But I have no idea why the stock firmware works fine. The address conflict should still exit.

Thanks.

===========================Update================================
I switched the order of address change and initialization of VL53 and it seemed to solve the problem. But I am not sure if there are any potentional problems by doing so.

/* Move initialized sensor to a new I2C address */

Code: Select all

  int newAddress;

  taskENTER_CRITICAL();
  newAddress = nextI2CAddress++;
  taskEXIT_CRITICAL();
  // return vl53l0xSetI2CAddress(dev, newAddress);
  vl53l0xSetI2CAddress(dev, newAddress);

  if (!vl53l0xInitSensor(dev, io_2V8)) {
    DEBUG_PRINT("vl53l0xInitSensor return false\n");
    return false;
  }
  else {
    return true;
  }
Also, I am still not clear why the stock firmware worked, because there should be address conflict as well.

arnaud
Bitcraze
Posts: 1609
Joined: Tue Feb 06, 2007 12:36 pm

Re: Initialization failed with two decks

Post by arnaud » Mon Feb 12, 2018 1:52 pm

Well, this is the problem with I2C: no one is never talking about the same address because on the bus the address is transmitted shifted left by. 0x52 / 2 = 0x29. The two I2C devices do share the same address.

Your I2C bus multiplexer starts with all secondary buses disconnected, as far as I understand your setup this is most likely why the stock firmware worked: your sensors are isolated from the bug when running the stock firmware.

When initializing the flow deck the VL53 driver moves the VL53 from its default address to a different one. This is done to accommodate the multi-ranger deck. In order to solve the initialization order problem in the multi-ranger deck, we are initializing the other sensors in the test function: https://github.com/bitcraze/crazyflie-f ... /oa.c#L114. This guarantees that any flow or z-ranger deck would have already initialized and moved its sensor out of the default address.

You should be able to have the same strategy: make sure your bus multiplexer is not allowing any of your sensors to be on the bus during init, and only start accessing your sensors from the test function and after the system has started.

One of the fundamental problem is that there is no way to set the initialization order of the deck drivers and I did not find any simple and elegant way of implementing it. This is why we had to use the test function to initialize the sensors.

Btw, I am curious as what type of sensors have exactly the same address as the vl53 range sensors

unario
Beginner
Posts: 8
Joined: Fri Jan 12, 2018 11:25 pm

Re: Initialization failed with two decks

Post by unario » Mon Feb 12, 2018 6:06 pm

I am using color sensors TCS34725 and its address is 0x29.

tobias
Bitcraze
Posts: 1666
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: Initialization failed with two decks

Post by tobias » Tue Feb 13, 2018 7:42 am

An I2C address conflict, that is a bit unfortunate. I'm guessing you are using the flow deck? Does the TCS34725 have a reset or shutdown pin? If so you could connect this and hold the reset while you change the address on the VL53.

Post Reply