Page 1 of 1
Initialization failed with two decks
Posted: Tue Feb 06, 2018 4:39 pm
by unario
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!
Re: Initialization failed with two decks
Posted: Wed Feb 07, 2018 1:37 pm
by arnaud
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.
Re: Initialization failed with two decks
Posted: Wed Feb 07, 2018 8:44 pm
by unario
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!
Re: Initialization failed with two decks
Posted: Thu Feb 08, 2018 8:12 am
by arnaud
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?
Re: Initialization failed with two decks
Posted: Thu Feb 08, 2018 6:11 pm
by unario
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.
Re: Initialization failed with two decks
Posted: Fri Feb 09, 2018 9:41 am
by arnaud
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.
Re: Initialization failed with two decks
Posted: Fri Feb 09, 2018 4:15 pm
by unario
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.
Re: Initialization failed with two decks
Posted: Mon Feb 12, 2018 1:52 pm
by arnaud
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
Re: Initialization failed with two decks
Posted: Mon Feb 12, 2018 6:06 pm
by unario
I am using color sensors TCS34725 and its address is 0x29.
Re: Initialization failed with two decks
Posted: Tue Feb 13, 2018 7:42 am
by tobias
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.