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.