Hi,
We noticed that sometimes our camera sensor appeared to get in a locked up state (due to application crash for example), but that resetting the Leopardboard using either the reset button or 'reboot' did not cure the condition - a power-down of the Leopardboard was needed. This can be a real pain if the camera is remotely located.
After tracing the schematics I found the camera sensor chip’s reset line is not driven from the CPU reset line, it comes off a GPIO line instead. (The selection is made by placement of a zero ohm link in R32 or R33 on the Leopardboard 365/368, R32 installed = reset from the CPU reset, R33 installed = reset from GPIO31, all our Leopardboards seem to have R33 installed, so GPIO31 is the reset).
I didn't want to modify our Leopardboards, and having an independent reset line can be useful anyway. So to get control of that GPIO line I then modified the BSP to enable GPIO31 in the pinmux, and allow control of it via the sysfs interface, by editing some files in kernel/linux-2.6.32/arch/arm/mach-davinci:
- In dm365.c, change the pinmux config: MUX_CFG(DM365, SPI2_SDO, 4, 8, 3, /*1*/0,false). This breaks SPI2 but it isn't used anyway, we want GPIO31 instead...
- In board-dm365-leopard, add #include <linux/delay.h> and add a couple of lines at the end of dm365_leopard_init() to setup and export the GPIO: #define DM365_GPIO31 DM365_SPI2_SDO davinci_cfg_reg(DM365_GPIO31);gpio_request(31,"CAMERA_RESET_GPIO31");gpio_direction_output(31,1);gpio_set_value(31,0);mdelay(100);gpio_set_value(31,1);
- We also added gpio_set_value(31,0);mdelay(100);gpio_set_value(31,1); into the detect part of our sensor driver (e.g. mt9p031_detect), so we can probe the device driver and reset it.
This all seems to work well and we can just assume our sensor will be properly reset after every Leopardboard reboot.
Comments?
Mark Lesha, ANSTO
I think you are doing the right way to reset the image sensor. As you discovered, sometimes it needs a reset independently. Toggling the GPIO31 will do the job.
Mark Lesha Hi, We noticed that sometimes our camera sensor appeared to get in a locked up state (due to application crash for example), but that resetting the Leopardboard using either the reset button or 'reboot' did not cure the condition - a power-down of the Leopardboard was needed. This can be a real pain if the camera is remotely located. After tracing the schematics I found the camera sensor chip’s reset line is not driven from the CPU reset line, it comes off a GPIO line instead. (The selection is made by placement of a zero ohm link in R32 or R33 on the Leopardboard 365/368, R32 installed = reset from the CPU reset, R33 installed = reset from GPIO31, all our Leopardboards seem to have R33 installed, so GPIO31 is the reset). I didn't want to modify our Leopardboards, and having an independent reset line can be useful anyway. So to get control of that GPIO line I then modified the BSP to enable GPIO31 in the pinmux, and allow control of it via the sysfs interface, by editing some files in kernel/linux-2.6.32/arch/arm/mach-davinci: - In dm365.c, change the pinmux config: MUX_CFG(DM365, SPI2_SDO, 4, 8, 3, /*1*/0,false). This breaks SPI2 but it isn't used anyway, we want GPIO31 instead... - In board-dm365-leopard, add #include <linux/delay.h> and add a couple of lines at the end of dm365_leopard_init() to setup and export the GPIO: #define DM365_GPIO31 DM365_SPI2_SDO davinci_cfg_reg(DM365_GPIO31);gpio_request(31,"CAMERA_RESET_GPIO31");gpio_direction_output(31,1);gpio_set_value(31,0);mdelay(100);gpio_set_value(31,1); - We also added gpio_set_value(31,0);mdelay(100);gpio_set_value(31,1); into the detect part of our sensor driver (e.g. mt9p031_detect), so we can probe the device driver and reset it. This all seems to work well and we can just assume our sensor will be properly reset after every Leopardboard reboot. Comments? Mark Lesha, ANSTO