raspberrypi/raspiraw

raspiraw not working after use of raspistill/raspivid

Closed this issue · 4 comments

Bosi1024 commented

Hi,

I have run into an issue that if I am using raspivid/raspistill and try to use raspiraw afterwards, raspiraw is not able to detect a camera anymore. If I only use raspiraw as described, it works fine. The specific symptoms are, that the i²c bus is timing out. Only a reboot fixes the issue.

System Specs:

  • RasPi 4B 4GB, RasPi CamV2
  • Linux raspberrypi 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux
  • Firmware: 
    Aug 31 2021 14:53:42
Copyright (c) 2012 Broadcom
version 67615e950e1e28b92dfae6303cf7a8b879a8908f (clean) (release) (start_x)
  • /boot/config.txt 
    dtparam=i2c_arm=on
dtparam=i2c_vc=on
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
start_x=1
gpu_mem=256
  • dmesg.txt

Maybe it is related to:

Kind regards

6by9 commented

Did you rerun camera_i2c? If not then the sensor will have been powered down by the firmware once it was finished with it.

If you have then this is probably an issue with the firmware and Linux having no way of co-operating over the use of BSC0 (the hardware block behind i2c-0 and i2c-10). They both think they are the only thing controlling it.
The kernel last set the pinmuxing to i2c-10 (GPIOS 44&45 on a Pi4), so as it believes nothing else will have changed that, the next access to i2c-10 won't set it again. Confirm by checking the output from raspi-gpio get for GPIOs 44&45.
You can try forcing Linux to reselect the pinmuxing by using sudo i2cdetect -y 0 to switch to GPIOs 0&1, and then it will reset it on the next access to i2c-10.

Bosi1024 commented

I have issued camera_i2c after using raspivid/-still to no avail.

Thank you for your diagnosis of the underlying problem and the insight into the workings of the I²C bus usage patterns.

Indeed, what happens is as follows:

  1. Clean start of the RPI, issuing camera_i2c followed by raspi-gpio get leads to the following output for GPIO 44&45: 
    GPIO 44: level=1 fsel=0 func=INPUT pull=UP
GPIO 45: level=1 fsel=0 func=INPUT pull=UP
  2. Running raspiraw and checking with raspi-gpio get leads to the following output for GPIO 44&45: 
    GPIO 44: level=1 fsel=5 alt=1 func=SDA0 pull=UP
GPIO 45: level=1 fsel=5 alt=1 func=SCL0 pull=UP
  3. Running raspistill and checking with raspi-gpio get leads to the following output for GPIO 44&45, again: 
    GPIO 44: level=1 fsel=0 func=INPUT pull=UP
GPIO 45: level=1 fsel=0 func=INPUT pull=UP
  4. Running raspiraw again (failing to find a camera) and checking with raspi-gpio get leads to the following output for GPIO 44&45, again: 
    GPIO 44: level=1 fsel=0 func=INPUT pull=UP
GPIO 45: level=1 fsel=0 func=INPUT pull=UP

Testing if your fix succeeds:

  1. Issuing sudo i2cdetect -y 0 , camera_i2c and checking with raspi-gpio get leads to the following output for GPIO 44&45, again:

    GPIO 44: level=1 fsel=0 func=INPUT pull=UP
GPIO 45: level=1 fsel=0 func=INPUT pull=UP

  2. Running raspiraw (succeeding) and checking with raspi-gpio get leads to the following output for GPIO 44&45:

    GPIO 44: level=1 fsel=5 alt=1 func=SDA0 pull=UP
GPIO 45: level=1 fsel=5 alt=1 func=SCL0 pull=UP

Sometimes the timing between 4./5./6. is critical. If running the commands too quickly:

  • sudo i2cdetect will not succeed (retrying helped) or
  • the subsequent raspiraw command is not able to find a camera. For me it was necessary to run camera_i2c a second time and retrying raspiraw.
Bosi1024 commented

Hi,

for me the issue is resolved. As it boils down to a firmware issue, where would be the right place to address it? I guess I could open an issue here.

Any thoughts?

6by9 commented

Sorry, not viewed as a bug.

BSC0 should be assigned to either the firmware for use in the camera stack (or DSI display touchscreen), or Linux. Using from both is going to cause issues, and not a supported mode of operation.
Potentially we could fix the pinmuxing, but that still only solves the problem if firmware and kernel are used sequentially. Issue a command from both simultaneously and the fight gets worse.