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.
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
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.
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?
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.
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.
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 (kernel lacks cgroups or memory controller not avaiable, not - Raspberry Pi Forums) 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”.
There are 2 possible causes (I was able to reproduce):
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
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 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
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?
“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).
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.
