eeprom

Che. · Post by **Che.** » Fri Oct 23, 2015 12:33 pm

after experimenting with the i2c1 device (resetting, deinitializing, reinitializing, writing some data, etc) i dont get no response anymore from the eeprom, even when i comment out all my code and flash the "original" version to the crazyflie.

console says I2C Connection failed.

any suggestions? did i brake something?

greets
Che.

edit:
loaded a clean version of the VM (clean build) and still the same problem

Che. · Post by **Che.** » Sun Oct 25, 2015 6:24 pm

I might have overwritten some of the registers in the eeprom. Actually testing of the eeprom doesnt work anymore.
Maybe its possible to rewrite the original state of the eeprom by someone? Can anyone provide me the state in his eeprom, so i can actually write it back to mine?

Greets

Post by **arnaud** » Mon Oct 26, 2015 1:57 pm

Hi,

Can you check that you are not shorting the I2C bus from the expansion board. The EEPROM is connected on the same bus as the one available on the expansion port.

Normally the EEPROM would be re-written on Startup if it is found to be corrupted (this is actually what is happening in factory: the first time a Crazyflie starts it writes a default state in the EEPROM).

You could also try to flash the latest binary to be sure you are running a clean version.

Che. · Post by **Che.** » Mon Oct 26, 2015 2:46 pm

Hi Arnaud,
thanks for your quick reply.

arnaud wrote:Can you check that you are not shorting the I2C bus from the expansion board.

I disconnected everything from the crazyflie as seen in my attached photo. Does this suffice to check if there are no short circuits?

arnaud wrote:You could also try to flash the latest binary to be sure you are running a clean version.

I did this by flashing the 2015.08 release in the desktop client (GUI).
I still get the same error.

Post by **tobias** » Tue Oct 27, 2015 1:13 pm

My best guess is that either it is the EEPROM that is broken or the bus that is shorted. You can check the bus by measuring the SDA and SCL pins on the expansion port. They should be around 3V when the CF2 is powered. The SDA and SCL pins are marked PB7 and PB6 on the bottom of the PCB. The EEPROM is the 5 leg ship just beside.

Che. · Post by **Che.** » Tue Oct 27, 2015 2:10 pm

Hi Tobias,
thanks for your answer.

tobias wrote:My best guess is that either it is the EEPROM that is broken or the bus that is shorted. You can check the bus by measuring the SDA and SCL pins on the expansion port. They should be around 3V when the CF2 is powered. The SDA and SCL pins are marked PB7 and PB6 on the bottom of the PCB. The EEPROM is the 5 leg ship just beside.

I just measured SDA and SCL pins. SDA is on 2.99V so thats ok.
But SCL pin is only on around 0.04V so it looks like its shorted.

Is there a way to fix this? And what can be the cause of the short circuit (better know that, to avoid it in the future when experimenting)?

atomicdog · Post by **atomicdog** » Tue Nov 03, 2015 4:56 am

But SCL pin is only on around 0.04V so it looks like its shorted.

Is there a way to fix this?

Check for shorts near the expansion port. Either there's a solder short or one of the IC's is holding down the SCL line, which may mean the IC is dead.

Che. · Post by **Che.** » Tue Nov 03, 2015 10:23 am

atomicdog wrote:
But SCL pin is only on around 0.04V so it looks like its shorted.

Is there a way to fix this?
Check for shorts near the expansion port. Either there's a solder short or one of the IC's is holding down the SCL line, which may mean the IC is dead.

I cant see any solder short with the naked eye. Maybe I am missing something? Could you give it a look? I hope the resolution suffices to see the details, i needed to scale it down because of size restriction.

Post by **tobias** » Tue Nov 03, 2015 12:23 pm

The question now is if it is the eeprom or the stm32f4 that is shorting the SCL pin to GND or if there is an external short (which I see as unlikely). It can also be that the SCL pull-up resistor is broken or not connecting to the pads. Easiest is to check the resistor first.

Unplug the battery and measure resistance between:
SCL (PB6) and GND -> Should be no connection
SCL (PB6) and VCC -> Should say ~2.2kOhm

If there is a low resistance to GND the stm32f4 output stage has probably shorted to GND. Could be tested by making a firmware which puts PB6 in high state but if there is an external short to GND or the eeprom is shorting to GND it can be a bad idea.

It should be pretty hard to break the pin output stage so I''m not sure that is the case. I've never managed to do it an I have shorted pins plenty of times. However if an higher voltage (like about 5V) have accidentally been connected to the pin it might fry quickly.

Che. · Post by **Che.** » Tue Nov 03, 2015 2:19 pm

tobias wrote:Unplug the battery and measure resistance between:
SCL (PB6) and GND -> Should be no connection

>>> Is 1.9kOhm

tobias wrote: SCL (PB6) and VCC -> Should say ~2.2kOhm

>>> Is 1.3kOhm

tobias wrote:If there is a low resistance to GND the stm32f4 output stage has probably shorted to GND. Could be tested by making a firmware which puts PB6 in high state but if there is an external short to GND or the eeprom is shorting to GND it can be a bad idea.

So I better not test it that way? It seems like the output stage has shorted, right?

tobias wrote:However if an higher voltage (like about 5V) have accidentally been connected to the pin it might fry quickly.

That might have happened. I am experimenting with the LIDAR LITE 2 http://pulsedlight3d.com/. For that I used an external voltage source with about 5V. Despite I was cautious while experimenting, it may have happened.

Bitcraze Forums

eeprom

eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom

Re: eeprom