Emlid

[SOLVED] "AK8963: bad DEVICE ID" error during Ardupilot start


(Dmitri Arekhta) #1

During each start of Ardupilot I’m keep getting “AK8963: bad DEVICE ID” error. I’ve tried AccelGyroMag, but it shows only this:

Acc: +0.000 +0.000 +0.000 Gyr: +0.000 +0.000 +0.000 Mag: +0.000 +0.000 +0.000
Acc: +0.000 +0.000 +0.000 Gyr: +0.000 +0.000 +0.000 Mag: +0.000 +0.000 +0.000
Acc: +0.000 +0.000 +0.000 Gyr: +0.000 +0.000 +0.000 Mag: +0.000 +0.000 +0.000
Acc: +0.000 +0.000 +0.000 Gyr: +0.000 +0.000 +0.000 Mag: +0.000 +0.000 +0.000
Acc: +0.000 +0.000 +0.000 Gyr: +0.000 +0.000 +0.000 Mag: +0.000 +0.000 +0.000

Does it mean that I have faulty IMU on my Navio+? RPi 2 is used.


IMU Magnetometer values all zero
(Mikhail) #2

Could you please run AccelGyroMag right after the power cycle, without running ArduPilot before, does it show the same?


(Dmitri Arekhta) #3

Yes, it’s actually the same.


(Mikhail) #4

Well, seems like something is wrong with MPU9250 on your board. Please send an email to info@emlid.com with information about your order (what was your order number or what email you used for it) and we’ll organize a replacement for you.


(Mathew Oxenham) #5

Did you sudo AccelGyroMag? (tho mikhail is probably correct if its saying bad device for the ak8963 but worth checking to see where the problem lies)


(Igor Vereninov) #6

@DaemonES Do all other examples work? Like LED, barometer or ADC?


(Dmitri Arekhta) #7

Sure, I’ve used sudo, but it didn’t help.


(Dmitri Arekhta) #8

GPS, LED and Barometer samples are working correctly, AccelGyroMag and AHRS are not. I can’t test PPM-Decoder and Servo due to lack of equipment. Also I will try FRAM today and let you know.

MPU9250 is QFN packaged, it’s more likely that my soldering skill is not good enough to fix it :slight_smile:


(Mikhail) #9

Don’t worry about the PPM, Servo or FRAM, the situation is clear - MPU9250 is not properly soldered or damaged. We’ll send you a replacement board, just contact us at info@emlid.com.


(João Fortuna) #10

Hi,
I’m having a similar problem, I get the same error message when running ArduPlane, but when running AccelGyroMag it seems that only the Magnetometer has issues.
Mag is always 0, while Acc and Gyr change…

Is the board defective or have you found a way to fix this?

Cheers


(João Fortuna) #11

Update:
Restarting the board via command line did not fix it, but powering off and on again seems to have fixed it.

Update2:
It seems that the error returns after some time of being powered on… Is this a thermal issue?


(George Staroselskiy) #12

@JFortuna

Don’t worry, that’s not a thermal issue. The error will go away after powering off. We’re trying to track down this issue, but it happens very rarely after a reboot. If APM lauches without errors, AK8963’ll work as expected.


#13

Hi,
same issue, ak8963 bad device id, preventing ardupilot start. Before that, there was another error during the system running, which terminated the ardupilot.

“PANIC: failed to take _spi_sem 100 times in a row, in AP_Compass_AK8963::_update”

All the examples are working properly though, including AccelGyroMag.
Noticed another error during system launch - " FATAL: Module spi-dev not found", not sure if it has to do something with the error.

Any developments on this issue?

Thanks.


(Dmitri Arekhta) #14

By the way I have received my replacement and now Navio+ works flawlessly. Thanks again, guys!


(Igor Vereninov) #15

@artmx your issue seems unrelated, are you using our SD image? Do you have anything else running at the same time?


#16

@ivereninov yes, the RPi2 image from the “docs” section. No, nothing else is running.


(Tony Wall) #17

I have the same problem. Hopefully this is just a software/build issue?

I’ve searched the forums and checked the necessary blacklist entries are removed and modules added, manually and via raspi-config makes no difference. Multiple reboots and power cycles. Running lsmod shows spi_bcm2708 and “ls /dev” shows both spidev0.0 and spidev0.1.

AccelGyroMag produces values which change when I move the board. I also ran ADC, LED, Multithread, AHRS, Barometer. GPS runs but I am indoors at the moment, only the iTOW value increases. FRAM fails with “Memory test not passed” (all values were still zero after writing).

There is a warning at boot related to memory “Kernel lacks cgroups or memory controller not available, not starting cgroups.”. I fixed this by following instructions in this article (https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=87080) to add cgroup_enable=memory in /boot/cmdline.txt before elevator=deadline. The warning went away but still the same problems with SPI and FRAM test.

This is with image “emlid-raspberrypi2-raspbian-rt-20150401.img.xz”.


(Tony Wall) #18

SOLVED!!!

There are 2 possible causes (I was able to reproduce):

  1. You have to “Enable Device Tree” in the RASPI-CONFIG! Then the boot sequence is totally different and everything loads (assuming you also enabled I2C, SPI and both with start module at boot options!).

Here is the whole procedure on top of the default image (20150401):

Run RasPi-Config to ensure Device Tree (Kernel 3.18 driver) mode is enabled:

sudo raspi-config
8 Advanced Options --> A5 Device Tree --> Yes --> OK
8 Advanced Options --> A6 SPI --> Yes --> OK --> (Load by default/start-up) Yes --> OK
8 Advanced Options --> A7 I2C --> Yes --> OK --> (Load by default/start-up) Yes --> OK
  1. DO NOT OVERCLOCK! Speed must be set to “none/700Mhz”. If you change the setting you must power off with “sudo shutdown -h now” (then I removed the power for 10 seconds). Shame, does that mean NAVIO+ has timing issues?

APM now works with the usual start command, without the AK8963 error :slight_smile: I will continue to test to see if everything is working, but in APM Planner 2 it connects and all the horizon and parameters appear to be coming through :sunny:

The cgroups memory warning appears to be fixed with device tree (doesn’t make any difference when I add it to cmdline.txt).

The only remaining issue is the FRAM example, now with the system working it returns “Failed to write device(-1): Input/output error” because the data is always FF. Does anyone know if that can that be ignored or is there still some other error to correct?


(Mikhail) #19

“AK8963: bad DEVICE ID” error is most likely caused by a bug in APM’s initialization of MPU9250, which is hard to locate due to its occasional nature.

I2C and SPI are already enabled in our RT Raspbian images, there’s no need to do anything about them.
Also, It is unlikely that overclocking causes issues with SPI devices.

The error can be solved by powering off \ on the board, which you did - and that is what made it go away.

Don’t worry about the FRAM, it is not used by APM. We are using new revision of FRAM chip in a new batch and the example doesn’t work with it at the moment (will be fixed soon).


(Tony Wall) #20

Thanks for the confirmation about FRAM but in my case it’s not true what you say about the cause of the bad device ID. I can really reproduce the problem by enabling or disabling device tree. With device tree disabled (the default on the image) it mostly failed so I guess that’s where your power down workaround comes from. That is no solution either, I expect the product to be stable.

The “enable device tree” solution permanently fixes the problem for me, on RasPi2. Every time I reboot or power down in any way it just works (done about 20 tests so far, clean and dirty reboots, shutdown or power loss).

That solution also makes sense if you look at other forum posts from people with difficulty using SPI or I2C on Raspberry Pi generally (the impact is wider than just NAVIO). Besides the module checks we know Emlid already have done correctly, the other solutions state since kernel 3.2.X the “new” device tree was added which broke SPI or I2C for many builds.

The spidev module doesn’t load on my RasPi2 when device tree is disabled. I guess the code in spidev (or related item) requires device tree then. I doubt it’s my specific hardware as a hardware problem would not behave like that.

Anyone with this error has something else to try at least. It would be good if Emlid could at least have a go at reproducing this error and consider enabling device tree as standard regardless, if that is the current device managememt system anyway.

I’m about to order another NAVIO and RasPi2 anyway to complete some other projects now I know it works, so will be able to compare results on a second system within a week or two.