Running CHDK with battery door open

  • 72 Replies
  • 5400 Views
*

Offline waldo

  • ***
  • 238
Running CHDK with battery door open
« on: 19 / October / 2010, 22:46:49 »
Advertisements
I got tired of opening the battery door to reload the SD card each time I wanted to test a new version so I made a piece of plastic to keep the battery door switch contact closed.  This became inconvenient when it slipped out of position or I needed to remove it to use the camera.  So I thought I would investigate a software-only way to boot the camera with the battery door open.

I found (to my surprise) that the camera would load and run CHDK even with the battery door open.  However, the camera shuts down less than a second after starting to run my_kbd_read_keys().  Through trial and error I found the physw_status[] word and bit corresponding to the battery door switch.  By setting this bit high within my_kbd_read_keys(), I can boot the camera with the door closed and then open the door without having it shut down.  But I cannot find a way to boot and stay on when powering up with the door open.  I know I'm getting to my_kbd_read_keys() before the camera shuts down, but setting bits in physw_status[] doesn't seem to be enough to prevent the power-down.

Has anyone tried this?  It would be a nice convenience to be able to do this when developing.

*

Offline reyalp

  • ******
  • 10069
Re: Running CHDK with battery door open
« Reply #1 on: 19 / October / 2010, 22:59:42 »
That's quite strange that it starts but then shuts down. Maybe there is a timed shutdown started before your code runs ? I would guess opening the battery door tries to do a safe shutdown, so it might not be instant.

What if you boot (with CHDK), open the door, and do a firm update ?

Or use PTP ;)
Don't forget what the H stands for.

*

Offline waldo

  • ***
  • 238
Re: Running CHDK with battery door open
« Reply #2 on: 20 / October / 2010, 00:11:38 »
I did another experiment.
If I startup with the door open and set the physw_status bit high and go into an infinite empty while loop, the camera stays on (but is hung, of course).
If I add a call to msleep() inside the infinite while loop, it shuts down right away just as if there was no while loop.
This seems to suggest that there is another task running that is doing a shutdown, as reyalp said.
Maybe if I can get a pointer to this task, I can intercept it inside taskCreateHook() ?

*

Offline reyalp

  • ******
  • 10069
Re: Running CHDK with battery door open
« Reply #3 on: 20 / October / 2010, 01:26:42 »
For anyone else interested in this, the code of the GetBatteryCoverClose eventproc may help you figure out which bit the switch is on.

Possibly related, there are also OpenBatteryCover and CloseBatteryCover events.

@waldo
It seems like whatever is triggering your shutdown might be reading the MMIO directly, or calling some other function that does, rather than using physw_status values.
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 10069
Re: Running CHDK with battery door open
« Reply #4 on: 31 / October / 2010, 00:46:50 »
On D10, this is physw[2] bit 0x8000. Found from GetBatteryCoverClose (which looks in a table that tells it the physw word and bit)

Similar to what waldo described, the camera doesn't start the door is open, but I can open it after it's running.

Doing a firm update with the door open doesn't (visibly) boot, which implies something early in the stock firmware boot process is checking and shutting down.

Would people want this as a conf option ?
edit: hmm, you'd probably need to set it long before conf is read

edit:
If I put a delay loop (0x400000 NOPs) one function call before the one that creates task_Bye, I can boot with the battery door open. I thought that function had something to do with the shutting down, but it still doesn't boot if I comment it out.
« Last Edit: 31 / October / 2010, 04:25:30 by reyalp »
Don't forget what the H stands for.

*

Offline waldo

  • ***
  • 238
Re: Running CHDK with battery door open
« Reply #5 on: 31 / October / 2010, 10:14:21 »
A more crude, but effective, way to determine the bit is to look at the physw values using Misc Values and see which "1" bits cannot be explained by any known switches.  This is what I did and I got it on the second try.  On the S95, the bit position is the same as for the D10.

Re: Running CHDK with battery door open
« Reply #6 on: 27 / November / 2010, 13:30:39 »
If I put a delay loop (0x400000 NOPs) one function call before the one that creates task_Bye, I can boot with the battery door open.
Tried this with my SD940 port and it works !!!   Many thanks - I was getting worried about the wear and tear on the battery & SD card door.

Not sure why it works either except that the first time my_kbd_read_keys() runs, there is already data (i.e. not zero) in physw_status.  So there might to be a race condition where the keyboard task needs to run and mask the cover door bit in physw_status before the task that monitors the cover switch status can run ? The extra delay in the task startup list lets that happen?

*

Offline reyalp

  • ******
  • 10069
Re: Running CHDK with battery door open
« Reply #7 on: 27 / November / 2010, 16:22:45 »
If I put a delay loop (0x400000 NOPs) one function call before the one that creates task_Bye, I can boot with the battery door open.
Tried this with my SD940 port and it works !!!   Many thanks - I was getting worried about the wear and tear on the battery & SD card door.

Not sure why it works either except that the first time my_kbd_read_keys() runs, there is already data (i.e. not zero) in physw_status.  So there might to be a race condition where the keyboard task needs to run and mask the cover door bit in physw_status before the task that monitors the cover switch status can run ? The extra delay in the task startup list lets that happen?
I tried forcing the values of physw_status at that point in the code instead of waiting, but that was no go. Don't know. If you are using this a lot, you may want to try reducing the size of the delay, the only reason I used that value was because it was in my blinking code.
Don't forget what the H stands for.


Re: Running CHDK with battery door open
« Reply #8 on: 27 / November / 2010, 16:41:00 »
If you are using this a lot, you may want to try reducing the size of the delay, the only reason I used that value was because it was in my blinking code.

I changed the nullsub_2() call in the startup to my own version of nullsub_2().   The delay is really not noticable during startup - maybe 1/2 a second ?
 
Code: [Select]
...
        "BL      my_nullsub_2\n"
...

void __attribute__((naked,noinline)) my_nullsub_2() {
        asm volatile (
        "STMFD   SP!, {R4-R6,LR}\n"
        "LDR     R0, =0x400000\n"
"loop1:\n"
        "nop\n"
        "SUBS   R0,R0,#1\n"
        "BNE    loop1\n"
        "LDMFD   SP!, {R4-R6,PC}\n"
        );
}

Re: Running CHDK with battery door open
« Reply #9 on: 20 / January / 2014, 10:19:43 »
Hello, I am trying to make this work with my cameras too, but I am unsure what to do. This seems to be very closed to hardware and might harm the camera when it is done wrong, wight?

Could someone help me to figure out what to do on my SX200IS?

Thank you very much!

 

Related Topics