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

Tue Jun 23 09:03:04 PDT 2020

Have you tried swapping the cable between the mux board and the system
board?

On Tue, Jun 23, 2020 at 10:01 AM Oleg <support-list at support.elphel.com>
wrote:

> Hi,
>
> MULTI_PHASE_SDRAM is indeed not stored in any firmware. Instead it's
> remeasured every boot by the driver (drivers/elphel/multisensor.c)
>
> There are a few steps in init:
>
> 1. /etc/init.d/fpga (runlevel 41)
> runs first, detects the mux board and loads the x359.bit (line 289). Then
> sets some delays for mux ports. Then writes a message in /var/state/ctype
> used by 2.
>
> 2. /usr/html/autocampars.php (run by /etc/init.d/sync.sh (runlevel 90))
> invokes drivers
>
> 3. sensor drivers
> MULTI_PHASE_SDRAM is measured and set here.
>
> 4. back to /usr/html/autocampars.php
> applies stored values, launches compressor and other things. I will need
> to have a look why it would not override the value.
>
> ------------
> a.
>
>> HW needs replacement?
>
> Yes, probably.
>
> b. As a temporary fix - if you were to hardcode the value
> for MULTI_PHASE_SDRAM to get applied after the driver
> the best places would be
> * /usr/html/autocampars.php
> - use elphel_set_P_value(...) [preferable] or file_get_contents(<request
> line that works from /359/10359_controls.html>)
> or
> * /etc/init.d/sync.sh
> - after autocampars.php is called. using wget and the request
> line 359/10359_controls.html
>
> This needs testing. I might be able to do this later this week.
>
> Regards,
> Oleg
>
> On Mon, Jun 22, 2020 at 1:50 PM Simon Vogl <office at voxel.at> wrote:
>
>> 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> 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> 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
>>>> 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)
>>>>
>>>> _______________________________________________
>>>> Support-list mailing list
>>>> 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 listSupport-list at support.elphel.comhttp://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)
>>>
>>> _______________________________________________
>>> Support-list mailing list
>>> 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 listSupport-list at support.elphel.comhttp://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)
>>
>> _______________________________________________
>> Support-list mailing list
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200623/626ee4bd/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/20200623/626ee4bd/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/20200623/626ee4bd/attachment-0003.png>