> * Jan 1 00:01:03 Elphel353 kernel: 10359A did not respond after changing
> 10353 sensor clock frequency to 96MHz
> *
>
Jorick,
This line shows that something is wrong. What cable (length) do you have
between 10353 and 10359? If it a long one - can you try a short one?
825 printk("10353 sensor clock set to %d\n",(int)
thispars->pars[P_CLK_SENSOR]);
826 udelay (100);// 0.0001 sec to stabilize clocks
827 X3X3_RSTSENSDCM; /// FPGA DCM can fail after clock change, needs to be
reset
828 X3X3_SENSDCM_CLK2X_RESET; /// reset pclk2x DCM also
829 /// reset system and SDRAM DCMs on 10359
830 MULTISENSOR_WRITE_I2C16(I2C359_DCM_SYSTEM, I2C359_DCM_RESET |
I2C359_DCM_RESET90);
831 MULTISENSOR_WRITE_I2C16(I2C359_DCM_SDRAM, I2C359_DCM_RESET |
I2C359_DCM_RESET90);
832 multisensor_initSDRAM(thispars); /// init 10359 SDRAM
833 rslt=0;
834 MULTISENSOR_WRITE_I2C16_SHADOW(I2C359_I2CMUX, I2C359_I2CMUX_2MEM);
835 if (rslt!=0) { /// select memory/clock i2c bus
836 printk ("10359A did not respond after changing 10353 sensor clock
frequency to 96MHz\n");
So the other errors probably depend on that first one. It did not appear in
the previous logs but the 10359 bitstream is different between versions.
SDRAM phase errors are caused by lack of communication with the 10359 board
after the clock frequency is stepped up (we can try to rebuild FPGA
bitstream with higher drive strength of the clock output - it is set to low
value by default to reduce EMI).
You'll probably not need the below instructions right now (troubleshoot
possible cable problem first), but here they are anyway:
The current code is built with debug option (set on line 13 of
http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/os/linux-2.6-tag--devboard-R2_10-4/include/asm-cris/elphel/c313a.h?view=markup)
ELPHEL_DEBUG=1, each bit activates different output (some is from
inside
IRQ service and needs redirection of the output). For example, SDRAM phase
adjustment debugging can be activated (MDF24() macros in
http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/os/linux-2.6-tag--devboard-R2_10-4/arch/cris/arch-v32/drivers/elphel/multisensor.c?view=markup)
if you edit
vi /etc/init.d/fpga
http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/packages/initscripts/353/fpga?revision=1.25&view=markup
and add/change one of the first lines - there are some commented out there,
like)
#fpcf -gwpx 2 8 >/dev/null; #debug mask
with
fpcf -gwpx 2 1000000
that will activate MDF24() during boot (after the boot you can change DEBUG
parameter like any others)
Some of the other debug bits an be very "noisy" and even lock up the camera
(especially those that are in IRQ service), for them you may want to
redirect output to the ramdisk file with the command from telnet session:
printk_mod &
(same command repeated again will delete log and start over - see
http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/packages/initscripts/353/printk_mod?revision=1.2&view=markup)
after that the kernel log messages (used in all MDF**() debug macros) will
be redirected to the /var/html/klog.txt - you can see it in the browser at
http://camera_ip/var/klog.txt
Andrey
_______________________________________________
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
