CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD - page 11 - Creative Uses of CHDK - CHDK Forum

CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

  • 704 Replies
  • 169050 Views
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #100 on: 04 / November / 2012, 18:29:30 »
Advertisements

Quote "IR_RST_E iris reset ?"
I don't think I'm the right guy to answer your question.  If you can elaborate, maybe I can help.

reyalp is just suggesting IR_RST_E may refer to an iris reset error.

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #101 on: 04 / November / 2012, 18:53:26 »
reyalp is just suggesting IR_RST_E may refer to an iris reset error.
There are similar strings ending with either _S or _E, my guess would be Start and End.
00068160: M:SH_OPN_S -> shutter open start
00068160: M:SH_OPN_E -> shutter open end
00068170: M:ZM_RST_S -> zoom(lens) reset
00068220: M:IS_RST_S -> IS
00068390: M:IS_RST_E
00068510: M:FC_RST_S -> focus(lens)
00068580: M:FC_RST_E
00068580: M:FC_STB_S -> focus(lens) standby
00068670: M:FC_STB_E
00068890: M:ZM_RST_E
00068890: M:IR_RST_S -> iris reset
00069320: M:IR_RST_E


I found something that might be related, around the place where the assert happened:
sub_FF838CA8 calls sub_FF88484C, which might be more or less equivalent to WaitForEventFlag. There's an interesting argument passed in R2: 60000. WaitForEventFlag (the VxWorks version) expects its timeout argument in R2 too. So, my guess is that a certain condition fails to happen within 60 seconds, thus the assert. None of these helps us to move forward, just mentioning :)

What would help is a setting/flag which would cause the firmware to ignore certain hw elements.

*

Offline reyalp

  • ******
  • 14080
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #102 on: 04 / November / 2012, 19:02:47 »
I did the procedure twice to be sure, and in both cases it was exactly the same.  On the first pass I myself was perplexed why PTP went down but I was still able to shutoff the camera with the POWER button, ie clean shutdown with shutter closure and PDN. 
If this is reproducible, you can resolve this definitively by checking the timestamp on the romlog vs the time the behavior is observed. Make sure you account for any offset between your wall clock and the camera clock.

I've never seen a romlog generated without the camera shutting down.  Since the romlog you posted is an assert, it seems extremely unlikely that it would behave differently from other asserts. Then again, your camera is likely in a pretty confused state at this point.
Quote
Quote "IR_RST_E iris reset ?"
I don't think I'm the right guy to answer your question.  If you can elaborate, maybe I can help.
As Microfunguy says, it's not really a question, just speculation about the meaning of the string. Might be useful for anyone trying to reverse engineer that code.
Don't forget what the H stands for.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #103 on: 04 / November / 2012, 19:37:33 »
Quote "If this is reproducible, you can resolve this definitively by checking the timestamp on the romlog vs the time the behavior is observed. Make sure you account for any offset between your wall clock and the camera clock."
I've synced them up and will time-stretch the procedure to be on safe side, and include a time stamp at each step.  Because the camera does not go into REC mode, it would be better to set up an external timer on this computer too.  FYI, because I need to plug/unplug the ribbon cable each time to revive the camera, I am being prudent not to over-use and wear out the pins, but so far so good, force appears to be OK.


*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #104 on: 04 / November / 2012, 20:51:43 »
Clocks  (min:sec)  Wall 24:00 = Camera 39:00  |  diff = 15 min

Because I am moving between 2 computers and trying to do things across the room there is a few seconds error, but here are the results:

   wall clock >> camera clock

> Disconnect IRIS
> PUP -> PLAY // OK (SHUTTER is CLOSED) 
> poke()  // swallowed OK  8:00  >> 23:00
> REC ==> SHUTTER opens -- nice.  12:00 >> 27:00
> Camera does not go into REC (ie still "No Image" PLAY mode in live view), but, does not shut down
> PTP error after 1 minute 13:05 >> 28:05 (edit: if needed, a 2nd open window to test other commands)
> I shutdown using POWER BUTTON:  15:00 >> 30:00 means camera still active!  Note I intentionally shut down 2 minutes later.
> SHUTTER closes
> Camera shuts down
> PUP attempt
> Camera does not PUP (no USB) ==>> common after a major electrical aberration.
> Unplug AC adapter (to be sure)
> Reconnect IRIS  ==> Have to reconnect the offender to "revive" the camera.
> PUP OK  20:00 >> 35:00
> REC OK - camera back to normal.

ROMLOG infraction : 2012:11:04 20:28:02.  As I said, consistent with previous // a new curiosity to munch on!  Attached.

edit:
srsa must be doing something pretty far-reaching!
« Last Edit: 04 / November / 2012, 20:58:34 by SticK »

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #105 on: 04 / November / 2012, 21:23:10 »
srsa must be doing something pretty far-reaching!
No, it's really just a simple firmware variable with very limited effect.

Custom diskboot at https://subversion.assembla.com/svn/chdk-s1.bin/files/
If all goes well, it should disable this latest assert (but not the 60 second delay).

Code: (diff) [Select]
Index: platform/s90/sub/101a/boot.c
===================================================================
--- platform/s90/sub/101a/boot.c (revision 2247)
+++ platform/s90/sub/101a/boot.c (working copy)
@@ -326,6 +326,7 @@
  );
 };
 
+void install_custom_assert_handler();
 
 void __attribute__((naked,noinline)) task_Startup_my() {
 
@@ -344,6 +345,7 @@
         "BL      sub_FF83A9DC\n"
         //"BL      sub_FF83323C\n" //; taskcreate_PhySw
  );
+        install_custom_assert_handler();
         CreateTask_PhySw(); // +
         CreateTask_spytask();  // +
     
@@ -963,3 +965,19 @@
 
  );
 };
+
+
+void __attribute__((naked,noinline)) customassert() {
+ asm volatile (
+    "LDR    R2, =0xFF879028\n"  //"SsStartupTask.c"
+    "CMP    R0, R2\n"
+    "CMPEQ  R1, #0x1ac\n"       //line number
+    "MOVEQ  R4, #0\n"           //need to fake "OK"
+    "BNE    sub_FF882824\n"     //no match, default assert handler
+    "BX     LR\n"
+ );
+}
+
+void install_custom_assert_handler() {
+    *(int*)0x1ad8 = (int)customassert;
+}

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #106 on: 04 / November / 2012, 21:51:55 »
NEW INSIGHT on SHUTTER CAMERA-CONTROLLER SIGNALLING and SticK-CONTROLLER BEHAVIOR

With the shutter controller circuit in http://chdk.setepontos.com/index.php?topic=8801.msg92704#msg92704 now functional (test configuration in the following post) it becomes easier and more reliable to measure the signalling, and thus refine our knowledge.  As it turns out, both OPEN and CLOSE signals are equal length, 7.8 mS (eg. Fig 1a, top trace, active LO).  This becomes a bit more interesting because the Uniblitz DSS10 is guaranteed to activate fully in 8.6 mS (O-C, ref http://www.uniblitz.com/resources_filelibrary/DSS10-Datasheet.pdf).  One could say the camera and the DSS10 are now pretty close, but, whereas the DSS10 *includes* mechanical lag in its 8.6 mS reaction time, for the camera, we don't know yet what that is.  At one point I will reassemble the shutter and use an optoswitch to determine whether the shutter reacts faster or slower than its Canon drive pulse of 7.8 mS.  One thing we can ascertain today however, is that after the leading edge of the CLOSE pulse, the camera will not begin readout or dark acquisition for *at least* 7.8 mS.

Also not seen earlier, Figure 1b and 1c show that Canon drives its shutter with a 275 kHz square wave during its OPEN or CLOSE pulse (camera solenoid powered is active LO in Fig 1b and 1c).  The duty cycle is slightly different for the two pulses, CLOSE being 63% and OPEN being 41%, or more likely, 60% and 40% respectively.  The probable reason for the HF PWM drive is to transmit high power over high-resistance thin long flat cable lines by favoring higher voltage over a longer time, resulting in a more efficient power transfer.  Recall that the power Canon can deliver is ~2.7W peak. 

Commercial shutters are specified for an unmodulated DC pulse.  Thus it is incumbent on the external controller to detect only the *first* rising edge of the Canon HF activation pulse train and ensure that the user can tune a shorter or longer DC activation pulse for his desired shutter spec, without it being continuously retriggered with the HF PWM tone as generated by the S90.  I designed this controller with a sleek little trick that I call "symmetrical retrigger lockout." That means only the very first edge is detected on an OPEN ACTIVATION *or* CLOSE ACTIVATION, and then the PRESENT ACTIVATION CHANNEL is immediately inhibited while the OTHER ACTIVATION CHANNEL is immediately enabled, until the OTHER ACTIVATION occurs emitting an opposite polarity DC pulse (changing shutter state) and inverting the input steering condition.  That way the SticK-CONTROLLER works uniformly with any kind of input signal you can throw at it, DC or modulated, and is a universal solution for any camera that uses a bistable shutter.  In essence, not only do we do a voltage level and current translation, but we also do a work translation which can handle the specialized Canon signal.  The LAMP ENABLE output also reacts to the first leading edge of the Canon activation HF pulse train, ensuring your scene illumination lamp will be OFF before readout begins.  For manual operation, you can tie the AUX INPUT to an SPDT toggle switch so long as it is break-before-make.  Debounce is intrinsic to the design so you don't need any input conditioning.

Figure 2 illustrates a SPICE simulation of the camera CLOSE activation by the pulse source V1 which is 5 Vpp 275 kHz 60% duty cycle tone.  The green trace is v(R1) and the blue trace i(R1).  Thus we can calculate with reasonable accuracy the length of an equivalent unmodulated 5 VDC pulse that would do the same work:
  Work{Fig 1a top} = P{steady state across R1}*t = (3.1V x 0.35A) * 7.8mS = 1.09W / 7.8mS = 8.5mJ
  Work{Fig 1a bottom}  must=  Work{Fig 1a bottom}
        hence:  8.5mJ   must=   new_P{steady state across R1} * new_t  must= (5V^2 / 9 ohms) * new_t
  new_t ~= 8.5mJ / (5V^2 / 9 ohms)
  new_t ~= 3.1 mS
Because current charge through R1 has inverse symmetry to current discharge, it is not necessary to use integrals in the equations to find new_t.

Hence in Fig 1a bottom trace, I demonstrate the external 5VDC drive pulse running the Canon solenoid I set to 3.1 ms for the CLOSE pulse (shutter is powered active HI) in this functional loop-back test for lack of a commercial shutter at this time.  As shown above, the solenoid activates because H-bridge Si9986 delivers approximately the same amount of work (Power x time, bottom trace) as the Canon signal (top trace) but over a shorter time.  However, if one were to load the solenoid with its vanes, it may not trip successfully at this pulse length because there may not be enough time spent delivering the total work to close completely.  For the DSS10 for example, you'd simply tune the trimpot to 8.6 ms (OFF-transition to the left of the 9th vertical division) and you're off to the races.

TIP: you may note that the DSS10 will draw 1.5A of current at 12V.  That does not mean you need a 1.5A power supply to run this shutter.  By installing a 4700uF capacitor close to the power connector, you can get away with a 100 mA supply easy, because if I recall, the shortest worst-case shutter duty cycle on the S90 is 1/2 second (for image transfer only) wrt say 10 mS max, which is 1:50.  So there is plenty of time between a CLOSE and OPEN image transfer activation signal pair to fully recharge the capacitor with a low current power source, and likewise with the large capacitor, power supply impulse droop during activation will be negligible. 
« Last Edit: 08 / November / 2012, 12:51:40 by SticK »

*

Offline ahull

  • *****
  • 634
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #107 on: 05 / November / 2012, 16:40:20 »
Clocks  (min:sec)  Wall 24:00 = Camera 39:00  |  diff = 15 min

Because I am moving between 2 computers and trying to do things across the room there is a few seconds error, but here are the results:

   wall clock >> camera clock

> Disconnect IRIS
> PUP -> PLAY // OK (SHUTTER is CLOSED) 
> poke()  // swallowed OK  8:00  >> 23:00
> REC ==> SHUTTER opens -- nice.  12:00 >> 27:00
> Camera does not go into REC (ie still "No Image" PLAY mode in live view), but, does not shut down
> PTP error after 1 minute 13:05 >> 28:05 (edit: if needed, a 2nd open window to test other commands)
> I shutdown using POWER BUTTON:  15:00 >> 30:00 means camera still active!  Note I intentionally shut down 2 minutes later.

Strikes me that at this point the camera is waiting for feedback (from the iris perhaps), hence the fact that it has opened the shutter, but not closed it again, so presumably this is the routine has been called that has failed to return?

Can we hook into *that* routine and return true (or whatever is expected) immediately? Failing that, Is there an optocoupler or hall sensor associated with the iris mechanism, if so what signals do we see from its output when connected (I  would assume a short pulse)? Can we supply a suitable fake signal, either by  playing with the associated GPIO with a poke {addr}{value};sleep {x ms}; poke {addr}{newvalue} or worst case, by soldering to the camera? 

> SHUTTER closes
> Camera shuts down
> PUP attempt
> Camera does not PUP (no USB) ==>> common after a major electrical aberration.
> Unplug AC adapter (to be sure)
> Reconnect IRIS  ==> Have to reconnect the offender to "revive" the camera.
> PUP OK  20:00 >> 35:00
> REC OK - camera back to normal.

ROMLOG infraction : 2012:11:04 20:28:02.  As I said, consistent with previous // a new curiosity to munch on!  Attached.

edit:
srsa must be doing something pretty far-reaching!

Not sure if this helps, but I did find a couple of schematics for some older canon models, a while back and posted the links on this forum...

http://chdk.setepontos.com/index.php?topic=7936.0

There are schematics for the ixus 60/65 and the S3 ( the 60/65 is not so interesting as it has an ND filter, not an iris, but good for comparison, you can see the two designs are very similar from an electronic perspective).

I doubt if the basics have changed much, although looking at the S3 diagram, it seems in that case, the iris has no obvious external feedback circuitry, so I could be on the wrong lines (or possibly the mechanism on your camera differs in some way). 
« Last Edit: 05 / November / 2012, 17:34:22 by ahull »


Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #108 on: 05 / November / 2012, 17:38:08 »
....
Also not seen earlier, Figure 1b and 1c show that Canon drives its shutter with a 275 kHz square wave during its OPEN or CLOSE pulse (camera solenoid powered is active LO in Fig 1b and 1c).  The duty cycle is slightly different for the two pulses, CLOSE being 63% and OPEN being 41%, or more likely, 60% and 40% respectively.  The probable reason for the HF PWM drive is to transmit high power over high-resistance thin long flat cable lines by favoring higher voltage over a longer time, resulting in a more efficient power transfer.  Recall that the power Canon delivers to its solenoid is ~2.7W peak. 
It is noral practice to drive inductive loads with a pwm signal. The inductance of the load resist current change and would in this case add a noticable response delay in the shutter assembly. By driving the inductance with a (much) higher voltage the current through the inductance rises much faster, resulting in a faster reaction time. If you would only up the voltage the current through the inductor would get too high resulting in overloading the inductor. So a pwm signal is used. The pwm should go to 0 when the max. current is reached. Usually you would measure the current and as soon as the max is reached the pwm drops to zero. But when you use a spec'ed inductor and a stabilised voltage you can also use a pre-programmed pulse train.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #109 on: 05 / November / 2012, 18:43:12 »
@ahull
It would be very useful to review the my first 1-3 pages // many questions are answered there.

Quote "Can we hook into *that* routine and return true (or whatever is expected) immediately? Failing that, Is there an optocoupler or hall sensor associated with the iris mechanism, if so what signals do we see from its output when connected (I  would assume a short pulse)? Can we supply a suitable fake signal, either by  playing with the associated GPIO with a poke {addr}{value};sleep {x ms}; poke {addr}{newvalue} or worst case, by soldering to the camera?  "
Ideally we'd like to hook into the routine and I am sure that is something the experts can chime in on.  Your 2nd idea is interesting too.  I have explained the components quite in detail somewhere is this thread near the beginning.  Staying with the IRIS for now until we have a better handle, in short yes, there is a stowed photoswitch which likely gives a reference signal when firmware spins the motor in PLAY->REC while it unstows the IRIS stopping down from WIDEOPEN to f2, liveview idle.  Henceforth, the motor runs open loop when taking shots changing IRIS size and there is no feedback until REC->PLAY where likely FW gets confirmation of a good stow from the photoswitch.  FOCUS works very similarly for those two conditions.  The idea of soldering to the camera is what we want to avoid, because a) an external circuit would have to be very clever and track motor revolutions to know when to fake the pulse, b) it would have to recognize the difference between stow movement and shot movement (not easy) ... and c) it would be less universal (too camera specific).

@casrap
Quote "The inductance of the load resist current change and would in this case add a noticable response delay in the shutter assembly."
This all depends on how the solenoid is designed vs available size and signalling.  The biggest delay in a shutter is to get the mechanics in motion regardless how efficiently you've delivered the change-state activation signal.  If you overdrive it somewhat beyond its optimum driving specs, the delay will be the same.  Look at the DSS10 waveforms in their PDF.  If there is a finite mechanical transition speed, then using a PWM signal can reduce the work needed to change state wrt an equivalent DC pulse, based on the theory you mentioned. edit: A more supportive explanation would be to understand the difference between a plain inductor and a solenoid, whose electrical objectives are usually at odds.  In words rather than equations, an inductor is typically used in an oscillatory circuit involving AC signals, whose inductance is tuned in frequency neighborhood of the signal being processed through the circuit.  The purpose of a solenoid is to set up a static magnetic field in order to transfer energy to move an armature, and the faster you can set the field up at maximum strength w/o saturating the coil, the sooner you'll get the armature to move.   Thus the fastest excitation is a DC transition, and its presence is only needed until the armature has moved to its desired position.  The Canon shutter solenoid is an equivalent-series RL (9 ohms and 1.9 mH) whose time constant (L/R) is ~200 uS.  This is much greater than the period of the PWM signal (3.5 uS in Fig 1b and 1c) hence the inductive fraction is essentially insignificant compared to its DC resistance.  In effect, the fixed PWM 275 kHz tone acts as a "time-extended" DC pulse into a pure resistor of 9 ohms as far as the RL network is concerned, suggesting the driving signal is more a power-transfer efficiency feature I proposed earlier than anything else.

Quote "I did find a couple of schematics for some older canon models"
Very interesting // I'll have a closer look over time to see if they correlate with what I have found empirically.
« Last Edit: 06 / November / 2012, 10:54:28 by SticK »

 

Related Topics