Sorry for recreating the topic, I didn’t realize I could edit the topic title.
I noticed a very strange pattern (to me) with the kernel panics and the camera on the Duo 256 MB. So, I tried the camera sample again this morning and it was miraculously working! I was playing with the RTSP stream for a short while, but the moment I set the camera down the Duo kernel panicked. I thought that it might be due to a poor connection to the camera so I reconnected everything. I started camera-test.sh while holding the camera again and it was working again. Wiggled the cables, etc. Seemed fine.
I then waved at the camera and boom - kernel panic. I’ve been playing with it a bit more and then realize that if i start the same with the camera in a well lit scene, and then slowly block the light coming into the camera, it will panic when the scene starts to get dark.
I modified the sample_vi_fd example to remove both the NPU usage and the RTSP stream - essentially just captures frames from the camera. The crash/panic still happens even when the video encoder and NPU are not being fed data. They always come from random parts of the kernel and from garbage instruction pointers, which would suggest to me that whatever is going wrong is corrupting kernel memory.
Could this be some kind of ISP bug related to auto-exposure / auto-focus? Are there any userspace/TDL SDK options I can tweak to reduce this behavior?
I can not provide answer, sorry. Rather I want to ask whether have you been using a precompiled kernel objects and SDK in your experiments with camera ?
Yes, this is with the stock image. Downloaded the milkv-duo256m-v1.1.0-2024-0410.img.zip image from Releases · milkv-duo/duo-buildroot-sdk · GitHub, wrote it to an SD card, booted my Duo 256 MB attached to USB, ssh’d in, and ran camera-test.sh.
Per another thread (on github, i think), I built the latest git version of the samples (GitHub - milkv-duo/cvitek-tdl-sdk-sg200x). I get the same result with the latest git version of the samples as I do with the samples bundled in the image.
I then started disabling random parts of the sample to see if the crashes would go away, but even when it’s just fetching frames from the camera, the crashes still happen. I want to stress that in my experiments, I’ve not modified the image, kernel, or kernel objects in any way. Just copied over a new sample_vi_fd binary from the git version of the samples.
The steps to reproduce are hold the camera pointed at a reasonably well lit room, start camera-test.sh, then cover the lens with your hand. It’ll then panic. Doesn’t matter if it ran for a few minutes pointed at good light, the moment you cover the lens, it crashes.
I’m facing the same problem here. I played with sample_vi_fd and sample_vi_od using both YOLOv5 and YOLOv8. No matter which script and network I use, after a while the board stops working and requires rebooting. I found out that the lightning might not be the only issue, the camera can be pointed at the same thing for the whole time, but sooner or later the board will stop running. I got quite interesting results while playing with VideoCapture from opencv-mobile. The script crashes after a while, but the board is still running. However, when I rerun the script, it says that camera cannot be opened.
Hopefully this observation will get us at least slightly closer to solving this issue (or at least it’ll draw the attention of the creators).
Deleting this option will reduce the frequency of the TPU. At the same time, the TPU processing power can only reach 0.5T. According to my test, there is no kernel crash problem when this option is turned on (but sophgo recommends that we do not turn it on on the current hardware). You can roll back this line of code and recompile to verify.
Does the CPU vendor have a timeline for when chips without this problem will be available? (I saw that the LicheeRV boards based on SG2002 have the same issue).
This is a problem with the Duo256M hardware. The voltage of one circuit is slightly low. We will fix this problem in the next hardware version. If you are willing to try to modify the hardware you have, I can provide a method. You only need to change a resistor.
Resistor R4 needs to be replaced with 118K, with a specification of 1%,0201. (The default resistance of this resistor in hardware version V1.0 is 110K)
