CHDK corrupted after starting camera with clock - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum
« previous next »
Pages: 1 2 [3]   Go Down

CHDK corrupted after starting camera with clock

  • 21 Replies
  • 11744 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK corrupted after starting camera with clock
« Reply #20 on: 19 / June / 2013, 06:18:29 »
Advertisements
Quote from: philmoz on 18 / June / 2013, 18:32:39
Quote from: srsa_4c on 18 / June / 2013, 16:57:59
To other devs who are reading this: I have only added the new
Code: [Select]
#define CAM_WAIT_FOR_FILESYSTEM         1define to platform_camera.h. If this build is working correctly, then this change can go into trunk, I guess.

@MotCan10
CHDK 1.1 and 1.2 are not compatible and can't really coexist on one card due to the different kind of modules they're using. PS.FI2 is only needed if you only want to start CHDK with the "Firm update" menu item. It's not needed for the "SD card lock" start method. It's missing from my test build because of a forum convention.
I have no idea about the blinking LED, this change should not be its cause.

I just realised the current CAM_WAIT_FILESYSTEM fix will break for partitioned cards - these still need to also wait for 'spytask_can_start' (to give the init_file_modules_task time to switch partitions).

Will post a patch soon.

Not sure why CAM_WAIT_FILESYSTEM would cause a startup delay - will do more testing on my cameras in case.

Phil.

I've removed the 'file_system_started' and CAM_WAIT_FOR_FILESYSTEM change.
It did not work all the time and could prevent CHDK from starting.

Back to the drawing board.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK corrupted after starting camera with clock
« Reply #21 on: 08 / August / 2013, 16:47:21 »
Some observations/thoughts on clock mode at startup.

Cameras that do have it, appear to emit either a "AC:BootClock" (old cameras) or "AC:BtClk" (new cameras) debug message upon reaching it in the startup process. Following this debug message, there is a firmware variable that gets set to a certain value ("1" in both the ixus65 and the a3200). The problem with this is the chance of race condition, I have no idea how fast the camera's boot process is compared to "our" spytask. The variable's default value seems to be 0.

I have briefly experimented on two cameras (see above), the removal of mkdir calls enabled CHDK to start in clock mode. Subsequent file operations were successful on the old Vx cam, and all file operations failed on the new DryOS one (including the reading of the config file!). Once clock mode was left, file operations have started to work.

A possible solution could be something like: enable the mkdir calls in spytask only when the above mentioned variable is "safe", i.e. 0
On DryOS cams which fail to load the config in clock mode, perhaps that default config shouldn't be saved when file operations start working.

And the good news: some low-end cameras don't have clock mode at all...
Logged
Pages: 1 2 [3]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal