RPi4: Purethermal 2 board not working #3136
Labels
Bug
Waiting for internal comment
Waiting for comment from a member of the Raspberry Pi engineering team
Comments
|
Updated to 4.19.66-v7l+ with rpi-update today. Still same exact issue. I've read it is because the camera is reserving too much bandwith. It works at full speed (12MB) when connected, not High speed (480MB). I've tried setting some quirks of the uvcvideo module, but still failing. I've also tested the RPi4 with other USB cameras and they work fine. Remember that everything is working fine under a Raspberry Pi 3B+ |
|
@P33M any ideas? |
|
Please post a full |
|
|
Ah. The connected port is in full-speed mode not high-speed. The max payload size for an isoc packet is 1023 bytes at full speed and the endpoint's single alt-setting is 962 bytes, but for some reason the bandwidth reservation is failing. What happens if you plug the device into a usb2.0 multi-TT hub and connect that hub to the Pi? |
|
Yes, the camera works in full speed. I've seen that on their repo, they say the camera works at Full Speed (12MB). The problem is that it works perfectly in a Raspberry Pi 3B+ with exactly the same code being executed (a simple python script that opens a VideoCapture and grabs frames). Here the output after plugging the camera on a HUB and to the Pi, still same exact error in dmesg: |
|
From lsusb for the terminus tech hub: You should find one that supports multi-TT operation. |
|
Oh, sorry I'll try to find one asap. |
|
After trying 7 different hubs, all of them appear as "1 Single TT"... Do you have any model that surely is Multi-TT? In Spain at least I find impossible to get one... |
|
Applying the patch to the Camera firmware described in groupgets/purethermal1-firmware#24 (comment) solves the issue for some pixel formats. It reduces the video packet size to half, resulting in the RPi reserving the correct bandwidth then. I don't know why, but all the other versions of Raspberry (at lest RPi2, and RPi3/RPi3 B+) work without this patch on the camera firmware. |
|
At least at interval 1, the stream bandwidth gets rejected at packet size somewhere between 642 and 802 bytes. |
|
I have a USB hub chip evaluation board that can be configured as a full-speed hub. If I plug the hub in, and then plug a cheap USB2.0 uvc webcam into the hub, I see the same issue. Bandwidth calculations are dependent on whether hubs are multi-TT or single-TT, and the hub inside the USB3.0 controller is single-TT. The full-speed hub forces the TT to be used so my test just confirms the issue relates to large isochronous packet sizes rather than the Purethermal 2. The largest isoc frame size for this camera in this mode is 956 bytes, with a 32-byte isoc endpoint for audio data and a 16-byte interrupt endpoint for events. The sum of all these is 1004 bytes, so it looks like the xhci driver might not be calculating bandwidth properly. |
|
Any news on this? |
|
Sorry for being a bit annoying, but I've been trying to look for where the possible error could be, but I'm totally unexperienced with kernels, and I don't know how to continue. Thanks |
|
The issue does appear with other full-speed devices with large isochronous endpoints. Most devices have fall-back endpoint max-packet sizes that allow for reduced bandwidth reservations - but the IR cam has a single alternate setting. From the video bitrates in the descriptors, it looks like all but the largest (160x120@24BPP) require less bandwidth than the 482-byte endpoint packet size provides. I would recommend using the modified firmware, as I currently don't have a timescale for a fix. |
|
Understood! Thanks P33M |
|
I can confirm that using a multi-tt hub doesn't solve the issue. The transfer is failing because the xhci controller is reporting "Secondary Bandwidth Error" when the endpoint gets enabled - implying the controller thinks that there is not enough periodic bandwidth available to add the requested transfer to the internal packet schedule. XHCI is supposed to have knowledge of hub topologies and maintain its own internal bandwidth allocations on a per-TT basis, so it appears that something is going wrong here. I've noticed something odd about the XHCI controller - it claims to be a rev 1.0 supporting device, yet in the HCCPARAMS1 capabilities field it does not support Secondary Bandwidth Domain reporting - a required feature. I can more easily probe the reservation size that causes the controller to barf through the use of the gadget driver g_webcam on a pi zero - it lets you specify arbitrary maxpacket sizes on its isochronous endpoint. |
JamesH65
added
Bug
Waiting for internal comment
|
The xhci controller is reporting secondary bandwidth errors when a full-speed isochronous IN endpoint is configured that has a maxpacket size of >792 bytes. I'm still investigating various configurations to see if this limit interacts with any other devices (i.e. if it's global or per-device), but I would recommend that, for now at least, you should ask the manufacturers of the camera to provide a firmware that limits the endpoint size to e.g. 768 bytes. |
|
Then I understand that is a problem from the xhci controller. The controller is specific for the RPI, because it is not happening on any other Linux device, no? I think that the Purethermal people have already deployed a patch that as you say limits the endpoint size. I'll keep roaming around here just to mantain myself and my company updated |
|
The issue is specific to the VIA PCIe-USB bridge chipset we are using on Pi 4. There is a firmware-imposed limitation of a total of 792 bytes of available full-speed Isochronous bandwidth shared across all attached devices. I am in active discussions with the manufacturer about what can be done to remove this limit. |
|
Stumbled upon this issue working on something similar, thank you for the multi-tt hub suggestion P33M. |
|
I had this exact same issue (PT2 + RPi4, 8GB), and there a few similar issues for this in the PT repos: The solutions here talk about rebuilding/reflashing the latest firmware- YMMV, but, for me, rebuilding and flashing the updated firmware 100% fixed things. It went from totally not working, to my old code (for an RPi3) working without modification! If you can, I really suggest you try building the latest firmware and flashing it via DFU, because I think @kekiefer has resolved this 😄 |
|
Oops I forgot to update this issue. There's a VLi firmware release that allows for use of up to 1023-byte isochronous endpoints here: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=273027 |
|
Apparently you can get similar symptoms if the module has become slightly unseated. Just a heads up for anyone else running across this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I've trying to obtain images on a newly baked RPi4 with Raspbian Buster from a PureThermal 2 board (https://groupgets.com/manufacturers/getlab/products/purethermal-2-flir-lepton-smart-i-o-module) that was working perfectly in a RPi3B+, but I'm totally unsuccessful.
I've seen that whenever I try to get a frame from the camera, using any method, I get the following error in dmesg:
I've tested it in both the USB2 and the USB3 ports of the Raspberry, but I always get the same error.
The device is detected correctly: I can see it detected in dmesg, I can see the /dev/video ports being created, and I can even extract information with v4l2-ctl. The problem only appears when I open the port and try to grab a frame
To reproduce
Connect the PureThermal2 board to an USB port
Wait for it to be detected and ready
Try to grab a frame with any method: Python, Opencv, FFmpeg, guvcview...
No frame is obtained, and it throws that error
System
RPi4 (4GB RAM)
cat /etc/rpi-issue)?Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 175dfb027ffabd4b8d5080097af0e51ed9a4a56c, stage4
vcgencmd version)?version a49274f4de9406db851802c64ea2e8a13df7e0d3 (clean) (release) (start)
uname -a)?Linux raspberrypi 4.19.63-v7l+ GPIO: polling a keyboard crashes the kernel after an hour or two... #1249 SMP Thu Aug 1 16:31:35 BST 2019 armv7l GNU/Linux
Logs
dmesglog after connecting the camera: dmesgAdditional context
I received the Raspberry Pi 4 around 2 weeks ago, installed Raspbian-Buster, updated everything, and copied the python code from a RPi3B+ where the PureThermal 2 board was working to it, installed dependencies (python, opencv, ffmpeg) and tried to grab a frame. I've been unsuccessful until now.
The text was updated successfully, but these errors were encountered: