Fatal error on MSS CPU: trap: 09, address: 802CE934' '0'
- Edited
I just attempted the Depth Preview example found here. Unfortunately I got the same error message and CPU trap address:
[14442C10619FF0D000] [3.2.1] [2.697] [system] [critical] Fatal error. Please report to developers. Log: Fatal error on MSS CPU: trap: 09, address: 802CE934 0
Traceback (most recent call last):
File "depth_test.py", line 51, in <module>inDisparity = q.get() # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message Couldn't read data from stream: disparity (X_LINK_ERROR)
By pure chance, I am running into the same error today after not using my Oak-D for a while (mine is also a kickstarter era model). I think it may be related to a lack of calibration information on my device. I do not seem to have valid calibration information in the EEPROM (cannot read it or reflash a factory config using the tools in the depthai-python/examples/calibration repo). As a result (I assume) I get this error anytime I attempt to do anything with the depth cameras.
The reason I logged on to the forum was to get some help with the calibration process - for some reason it seems to be running agonizingly slow, less than 1 fps with huge latency. I have tried it on Linux and Windows, with a variety of USB3 and USB-C cables. Maybe I am just spatially challenged, but I cannot get through the 39 image calibration routine with the frame rate running so slow - it's endlessly frustrating trying to find the right orientation of the board acceptable to the calibration script. Therefore I am unable to verify whether successfully flashing a new camera calibration will resolve the issue.
Is it normal for the calibration routine to run so poorly? The example in the video on the calibration trouble shooting page seems much smoother.
- Edited
That's definitely an intriguing development. In my case, I was able to successfully calibrate my OAK-D back during the summer of 2022 (originally the RGB wasn't working with Aruco markers the way I'd expected).
- Edited
My calibration script was a year outdated, so I went ahead and cloned the latest depthai repo with git clone https://github.com/luxonis/depthai.git
and ran the python3 install_requirements.py
inside a new virtual environment (just to be safe). When I tried to run the the calibration script it threw this:
I don't understand why this worsened things! Now my OAK-D no longer shows up when I run lsusb
, and all my other OAK-D scripts that were running fine yesterday are failing with the same error above. I'm still using the USB 3.0 cable, and the light on my OAK-D is coming on. So far I've tried resetting the udev rules with:
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="03e7", MODE="0666"' | sudo tee /etc/udev/rules.d/80-movidius.rules
sudo udevadm control --reload-rules && sudo udevadm trigger
However, that didn't fix anything
- Edited
After restarting my VM several times, the camera is now detectable. I ran through a calibration and was able to capture images and view reprojection error, but before it finished I received this error:
Should I retry calibration, resort to a factory reset, or perhaps something else?
Hi aiManny
I think there is a problem with the calibration script for your specific board. Could you create an issue at depthai repo and tag https://github.com/MaticTonin.
Thanks and sorry for the inconvenience,
Jaka