Hi John,
No worries, also apologies for the delayed response. I should have asked for the SDK version you are on since we started packaging a voxl-sparrow-utils package that has that mlanutl bin that was missing in a later SDK version, I included the deb in the installer which should hopefully install correctly.
Here is the new one to try with the README.MD with the instructions: https://drive.google.com/drive/folders/1SBCSf8_EZkkYV3GnvDhC2poD7ckjDLWq?usp=sharing , Thanks!
Hi John,
Thank you for the information it was very helpful for analysis.
It seems as though the firmware crash happens on stream timeouts and causes the firmware to crash.
Here is a potential workaround with the installer, I kept all the claude output in case that helps with any analysis on your end: https://drive.google.com/drive/folders/1sbwS3RZ4wgmC2raH7SnDKZz3OYSOavSg?usp=sharing
If you could try running that and using the device normally, hopefully that stops it from crashing. We also do have routing on that expansion board for the RESET pin but for some reason the firmware does not respect it. If you keep seeing the issue that might be the next place to look, but NXP has marked this chip as EOL and won't support any fixes there, so our best hope is to workaround whatever is happening.
Let us know how that goes and any other findings. Thanks!
Hi John,
Thanks for the data dumps. Could you run this wifi_capture.sh on your board and send us the data when you reproduce the crash along with the dump file again? It should be here along with a simple readme https://drive.google.com/drive/folders/14nMhkvOMeHJ6zLJYMW4scAglTfkRYY8N?usp=sharing
Could you also briefly describe how you are connecting/what devices you are connecting? Also does this happen under any specific workloads or is it sporadic? It seems like a firmware crash so any additional information would be very useful if we end up needing to report it.
Thanks!
Hi John,
We are still looking at the issue and trying to reproduce and will get back to you if we find anything.
If its possible could you also upload that /data/dump file to this ticket? If the size is not supported possibly uploading to google drive or similar file sharing service for us to inspect would be very helpful.
Thanks!
@mkriesel Hello,
I have pushed some changes to enable gpio64 as an input on the meta-vox2l-bsp branch link
To do that please follow the build docs here to rebuild the kernel image and to push it onto your device here
In the build docs, after you build the docker image and run it, add following line to qrb5165-common.sh top level file in the build docker
CI_META_VOXL2_BSP_BRANCH="feature/voxl2-mini-gpio64-export"
Then run the rest of the steps, sync patch and build, as normal to build the image.
Please also check if you need to build the kernel image with the -v var02 flag following the guide here - https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2 , with the variant type being the same for the voxl2-mini m0104
Let me know if that works for you!
Thanks,
-Luke
Hi @mkriesel, are you planning on using the UART functionality on the j10 connector?
Hi,
I don't believe that on the voxl2-mini anything is using that gpio so it might be possible to export. Let me look into that and get back to you.
For context are you just trying to use it as a regular GPIO like you are describing?
Thanks,
-Luke
