Robi_G1
Posts: 13
Joined: Wed May 15, 2019 7:23 am

Way of Detecting Bad Frame on MIPI Line?

Fri Jun 21, 2019 10:30 am

Hi all,

I'm using raspiraw on a project, and have a MIPI splitter MUXing 2 cameras to the pi. The cameras are triggered off of an external signal, but for a yet to be diagnosed reason, the cameras will sometimes trigger themselves, with the tail-end of this spurious data appearing at the pi when the splitter switches over to the misbehaving camera, resulting in a missed frame.
Attached image shows an example of when a camera triggers when it shouldn't. Both cameras do it though so it's unlikely to be a defective unit.

Regardless of the cause, losing a frame for any reason really messes up the output of the application.

Is there a way to detect a bad or partial frame in the MMAL buffers (or via some other mechanism)?

Many thanks,
Rob
Attachments
Camera Self-triggering.png
Scope output
Camera Self-triggering.png (39.67 KiB) Viewed 426 times

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6897
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Way of Detecting Bad Frame on MIPI Line?

Fri Jun 21, 2019 2:22 pm

It depends on what the data packet is.

MIPI has Frame Start (FS), Frame End (FE), Line Start (LS), and Line End (LE) short packets. The peripheral can also produce a line count interrupt (LC) every N lines.
LS and LE short frames do contain line numbers, and FS and FE contain frame numbers, but very few things look at them, and not all devices generate sensible numbers in them. I did investigate the frame numbers on ADV7282-M as it signifies the field on interlaced streams, but that's about the only time I've ever had need to look at them.

The rawcam component triggers on the FE to pass the buffer(s) back to the application, and tries on FS or LC to swap a new buffer in in readiness for the next frame (blanking periods can be very short, so you don't want to leave it to FE as you may be too late for FS).
Getting 2 FEs with no FS should be rejected as something invalid.

There are status registers for numerous error conditions: CRCs, parity, invalid sync codes, etc. Defines are in the bcm2835-unicam driver, but you may need to apply some deduction as to what they are. Sorry, I'm not at liberty to dsitribute the datasheet.

rawcam ignores all the errors and silently resets them.
bcm2835-unicam does likewise, but you could amend the driver to do differently - https://github.com/raspberrypi/linux/bl ... cam.c#L642
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Robi_G1
Posts: 13
Joined: Wed May 15, 2019 7:23 am

Re: Way of Detecting Bad Frame on MIPI Line?

Fri Jun 21, 2019 3:51 pm

Thanks, that's my Monday filled up nicely.

Robi_G1
Posts: 13
Joined: Wed May 15, 2019 7:23 am

Re: Way of Detecting Bad Frame on MIPI Line?

Thu Jul 04, 2019 1:09 pm

6by9 wrote: rawcam ignores all the errors and silently resets them.
bcm2835-unicam does likewise, but you could amend the driver to do differently - https://github.com/raspberrypi/linux/bl ... cam.c#L642
Following on from that advice, I've read half the Debain Admin' Handbook, the first couple of chapters of https://lwn.net/Kernel/LDD3/, and built the rpi kernel from source. Linux drivers (and everything else Linux-related really) are all very new to me, so I thought I'd keep things simple and add a load of 'printk' statements to bcm2835-unicam.c just to get something out of it.

Code: Select all

printk(KERN_ERR "#Hello World#");  //have also tried 'KERN_ALERT' with the same outcome.
I put these in the functions I assumed would be called by modprobe or rmmod commands (unicam_probe(), unicam_open(), unicam_release(), unicam_remove(), and a couple of others for luck.

Using the instructions here: https://www.raspberrypi.org/documentati ... uilding.md I rebuilt the kernel, and it appears to have detected a change to the bcm2835.c file (below).

Code: Select all

[email protected]:~/linux$ sudo make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage modules dtbs
scripts/kconfig/conf  --syncconfig Kconfig
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  GZIP    kernel/config_data.gz
  CC [M]  drivers/media/platform/bcm2835/bcm2835-unicam.o
  Building modules, stage 2.
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  MODPOST 1586 modules
  CC      drivers/media/platform/bcm2835/bcm2835-unicam.mod.o
  LD [M]  drivers/media/platform/bcm2835/bcm2835-unicam.ko
...and then when I install the modules to the boot SD card, it does the bcm2835-unicam module (again, below).

Code: Select all

[email protected]:~/linux$ sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=mnt/ext4 modules_install
... many lines ....
INSTALL drivers/media/platform/bcm2835/bcm2835-unicam.ko
... many more lines...
But when I then run '$sudo modprobe bcm2835-unicam' on the pi, nothing comes up in dmesg, and there's nothing in /var/log/kern.log either. I've tried running both raspistill and raspiraw to see if they load the module and call anything, but none of my error printings show up.

I then rebuilt the kernel on the RPi zero itself (~19 hrs), and it (the pi) still works. I tried my 'hello world' module on the pi. It prints things to dmesg just like it does in Ubuntu. But insmod and rmmod (whilst successfully loading the module, seen via '$lsmod | grep unicam'), don't do anything that gets logged.

So my questions are (sorry for the long preamble):
* Am I looking in the wrong place for logs?
* Do I need to do some more research? I thought that running raspiraw would load rawcam, which would load the unicam module, which would printk to the kernel log, but that seems not to be the case.

Return to “Camera board”