[Elphel-support] Elphel 353 / 359 stereo camera problem

Mon Jun 22 12:47:15 PDT 2020

Ok, I'm still puzzled and trying to get this back online...

As it seems, the MULTI_PHASE_SDRAM cannot be set in this revision. I 
tried also by setting it direcly in the autocamparams file (and synced, 
rebooted, checked the file) withoud effect.

Copying a settings file from a function camera has no effect either.

Besides: When I go to settings and change the shortly disable channel 2 
by clicking 'X' in the camctrl interface, the cam starts up again as it 
should, but when enabling channel 2 again, the second image does not 
show up any more, seems the WOI paramaters got lost:

One question - the dmesg log line

**** ERROR adjusting SDRAM clock phase in 
arch/cris/arch-v32/drivers/elphel/multisensor.c:1697:multisensor_adjustSDRAM

is caused somewhere by the /etc/init.d/fpga script (indirectly by 
applying the settings)?

One other thing: Exchanging the FPGA board resolves the issue, so there 
must be some persistent values stored on there?

If there's another place to look, I'd be thankful for clues...

Simon

Am 22.06.20 um 20:35 schrieb Oleg:
> Yes, 8.2.15 should be fine too... as long as you find the MULTI_* 
> parameters.
> Regards,
> Oleg
>
> On Mon, Jun 22, 2020 at 12:25 PM Simon Vogl <office at voxel.at 
> <mailto:office at voxel.at>> wrote:
>
>     Hi Oleg,
>
>     thanks for the timely feedback, let me answer inline:
>
>     Am 22.06.20 um 19:44 schrieb Oleg:
>>     Hi,
>>
>>     When stacking images vertically the mux board let's the 1st
>>     sensor (top image) through w/o buffering in SDRAM. The second is
>>     buffered. So, it could be SDRAM phase.
>>
>     Well, this is definitely involved - when I set the right clock
>     parameters, I could get reasonable picture content again (although
>     only on one image).
>>     1. What firmware version are you using?
>>     ~# cat /etc/issue
>>     or
>>     ~# cat /etc/release
>>
>     [root at Elphel353 /root]817# cat /etc/release
>     JFFSID="8.2.15"
>
>     close to .16 but not exactly - does an upgrade in the field make
>     sense?
>
>>     2. If the firmware is 8.2.16 (hopefully), then the phase settings
>>     are available through the camera parameters:
>>     http://192.168.0.9/autocampars.php -> check 'unsafe' - in the
>>     table you will find:
>>
>>         MULTI_PHASE_SDRAM
>>         MULTI_PHASE1
>>         MULTI_PHASE2
>>         MULTI_PHASE3
>>
>>     Check the values from a camera that works ok. And try to fix them
>>     for a bad camera from this autocampars page (not
>>     10359_controls.html, which communicates directly with fpga -
>>     cannot not store settings across reboots)
>>     Once you set the values, go back to
>>     http://192.168.0.9/autocampars.php and 'save' the config in the
>>     second table. Then reboot.
>>
>     ok great, will try it this way, guess that's what I was missing.
>>     3. Has anything changed recently? Like you stored a new
>>     configuration? Reboot often? Applied any changes?
>>     The camera stores and loads its firmware from flash -
>>     sometimes the fs or some file there would get corrupted when
>>     changes to the filesystem are applied but not properly synced.
>>     With a single lens camera most of the trouble was usually
>>     caused by /etc/autocampars.xml going corrupt. Then backing it up,
>>     removing the file and then rebooting (it autoregenerated on
>>     reboot if not there) might help. Note - if you manipulate files
>>     manually from a command line - run 'sync' when done. Then repeat
>>     step 2 if firmware is 8.2.16.
>>
>     The maintenaince guys did a few reboots last week (suspected
>     troubles with a poe switch) and I am hoping that this is the cause
>     of the trouble.... I bit-compared the bit files, they're identical
>     to a running camera. The xml files looked fine as well.
>
>     Will try around more and come back to you - thanks a lot!
>
>     Simon
>
>
>>     Regards,
>>     Oleg
>>
>>     On Mon, Jun 22, 2020 at 10:29 AM Simon Vogl <office at voxel.at
>>     <mailto:office at voxel.at>> wrote:
>>
>>         Dear all,
>>
>>         we have a bunch of 353-based stereo cameras that are in
>>         operation for seven years meanwhile and we've been very happy
>>         with them. Over the last weeks, some of them have image
>>         errors, at first sight it looks like one of the sensor is not
>>         configured correctly, a combined image looks like:
>>
>>         I found that this seems to be a problem with the 10359
>>         multiplexer board -- exchanging this resolves the issue for a
>>         camera.
>>
>>         When booting, the relevant portion of dmesg reports this
>>         error on the affected cameras:
>>
>>         arch/cris/arch-v32/drivers/elphel/framepars.c:390:initGlobalPars GLOBALPARS(G_DEBUG)=0
>>         initSequencers:resetting both sequencers
>>         arch/cris/arch-v32/drivers/elphel/framepars.c:420:initMultiPars GLOBALPARS(G_MULTI_NUM)=0
>>         Initializing DMA registers for EXTDMA3 -
>>         sensor clock set to 48000000
>>         10359 bitstream version =0x0359a054
>>         10353 sensor clock set to 96000000
>>         10359A sensor clock set to 96000000
>>         removing MRST from the sensor
>>         Found MT9P001 2592x1944 sensor on 10359A port 1, chip ID=1801
>>         Found MT9P001 2592x1944 sensor on 10359A port 2, chip ID=1801
>>         Setting internal HACT generation
>>         Found MT9P001 2592x1944 sensor, chip ID=1801
>>         arch/cris/arch-v32/drivers/elphel/framepars.c:420:initMultiPars GLOBALPARS(G_MULTI_NUM)=f
>>         **** ERROR adjusting SDRAM clock phase in arch/cris/arch-v32/drivers/elphel/multisensor.c:1697:multisensor_adjustSDRAM
>>         low90=3, low_l=249, high90=3, high_l=-250
>>         arch/cris/arch-v32/drivers/elphel/multisensor.c:1310:multisensor_pgm_sensorphase **** ERROR adjusting SDRAM clock phase in arch/cris/arch-v32/drivers/elphel/multisensor.c:1311:multisensor_pgm_sensorphase, result=0xffffffff
>>         Resetting MT9X001 sensor
>>         Reading sensor registers to the shadows:
>>         Initializing MT9X001 registers with default values:
>>         Starting hardware sequencers
>>         arch/cris/arch-v32/drivers/elphel/quantization_tables.c:211:init_qtable_head_cache
>>
>>         I have tried to set the clock parameters from a functioning
>>         specimen via the /359/10359_controls.html which temporarily
>>         resolves the issue, but after a reboot the problems reappear.
>>
>>         Any chance to resolve this in software or do we need to
>>         exchange boards? If so - are they still available?
>>
>>         All the best from Austria, stay healthy,
>>
>>         Simon
>>
>>
>>
>>
>>         -- 
>>         VoXel Interaction Design  |www.voxel.at  <http://www.voxel.at>
>>         DI Dr.techn. Simon Vogl   |simon at voxel.at  <mailto:simon at voxel.at>
>>         Tomaschekweg 46           |  +43 650 2323 555
>>         A-4040 Linz - Austria     |
>>         Office address: Industriezeile 35, 4020 Linz (2nd floor)
>>
>>         _______________________________________________
>>         Support-list mailing list
>>         Support-list at support.elphel.com
>>         <mailto:Support-list at support.elphel.com>
>>         http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>>
>>
>>
>>     -- 
>>     Best regards,
>>     Oleg Dzhimiev
>>     Electronics Engineer
>>     phone: +1 801 783 5555 x124
>>     Elphel, Inc.
>>
>>     _______________________________________________
>>     Support-list mailing list
>>     Support-list at support.elphel.com  <mailto:Support-list at support.elphel.com>
>>     http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
>     -- 
>     VoXel Interaction Design  |www.voxel.at  <http://www.voxel.at>
>     DI Dr.techn. Simon Vogl   |simon at voxel.at  <mailto:simon at voxel.at>
>     Tomaschekweg 46           |  +43 650 2323 555
>     A-4040 Linz - Austria     |
>     Office address: Industriezeile 35, 4020 Linz (2nd floor)
>
>     _______________________________________________
>     Support-list mailing list
>     Support-list at support.elphel.com
>     <mailto:Support-list at support.elphel.com>
>     http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
>
>
> -- 
> Best regards,
> Oleg Dzhimiev
> Electronics Engineer
> phone: +1 801 783 5555 x124
> Elphel, Inc.
>
> _______________________________________________
> Support-list mailing list
> Support-list at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com

-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon at voxel.at
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |
Office address: Industriezeile 35, 4020 Linz (2nd floor)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/09d86181/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hbbfcbpofmggbdnb.png
Type: image/png
Size: 965966 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/09d86181/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obnfpilahfcneomg.png
Type: image/png
Size: 46589 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/09d86181/attachment-0003.png>