I’ve just received my Navio2 and am running into some issues. The pi is a Raspberry Pi 3 Model B Plus Rev 1.3.
The CAT24C32 EEPROM chip is not showing up on the i2c-0 bus on address 0x50 as it should.
The only device showing up there is on 0x66, and I’m not sure what that is. I dumped the contents of the chip ( with a TL866+ programmer) and found it was empty, and happened to find HAT not detected - EEPROM possibly corrupt? this topic that describes a similar problem of the
/proc/device-tree/hat structure being missing, though his CAT24C32 did show up on the bus, and did have data stored in it. I checked the addressing pins on the chip (A0, A1, A2) and they are indeed all pulled low, the SDA and SCL traces also have continuity to the pins they should be connected to. I have not yet been able to verify that the CAT24C32 is being powered, I don’t have a male->female 40 pin cable atm so I can’t get to the chip while the hat is mounted. I plan to look at the bus with a logic analyzer, but I need to get the navio2 board away from the rpi so that I can actually attach probes to it.
As a result, the
/proc/device-tree/hat folder is never created, and emlidtool thinks there’s no hat installed:
The STM32 appears to be working, the example code (C++) seemingly all work. Another oddity is that
emlidtool rcio does not seem to recognize that the chip is there, but
emlidtool rcio update -f does indeed update the chip. I verified the firmware on the chip vs
/lib/firmware/rcio.fw using a blackmagic probe, the firmware is indeed written to the chip, and the resulting messages in
dmesg are as expected:
I did run into a problem last night where the forced upgrade suddenly hung and refused to complete, leaving the chip in an undefined state; this was very easily fixable by loading the fw binary with blackmagic and gdb directly.
Arducopter/rover 4.0 (haven’t tested anything else) also appears to work, but I haven’t done any extensive testing outside of sensor calibration, which so far has not had any issues.
vcdbg log msg: https://gist.github.com/jubaleth/b1a69ad3fab1784f70bdd6062953fe17
and for good measure, output of
i2cdetect -y 1:
EDIT: Picture of the board on the pi:
EDIT 2: Using the latest emlid raspbian image (Linux airpi 4.19.127-emlid-v7+ #1 SMP PREEMPT Mon Aug 24 19:50:57 MSK 2020 armv7l GNU/Linux), tried on 2 micro SD cards and 2 rpis now.
Anyway, I hope that I’ve provided enough information, I’m not really sure if my board is defective if it still works properly/reliably without the ID EEPROM, and if I should even worry that
emlidtool doesn’t recognize the board.