About a week ago while I was putting the SX40 back together after repairing it I managed to damage the end of the ribbon connector for the buttons on the back. After a few days trying to solder a hair-thin wire across each contact pad, all the buttons finally work (except for the power-LED as it's pad came off). I dare not open it up again in case the very messy repair stops working. Not to worry though, I have my other original SX40 which I can do some testing on.In case anyone's interested in what was wrong with it, it was a power issue on the mainboard. I had naively bought the second SX40 thinking that the missing battery door was the reason it was reported to not turn on. Unfortunantly when I got it I found that the door had been perposely taken off as a spare part, as the camera wasn't working. Swapping the mainboard around with the one on my working SX40 isolated the problem to the mainboard. Comparing voltages present on the decoupling caps located the 4 missing voltages. Bridging a largeish 3.3 volt supply on the mainboard to a missing 3.3 volt rail made all the other voltages return, and it powered on! I had plans to transplant the viewfinder from the "slave" camera to the side of the "master" to get a stereo preview, but had no way to reliably send the 27MHz signals through wires between the two, so I think I'll have to use a separate viewfinder rig running off the composite video outputs.The fix however has one side effect that I only just noticed now that I'm putting together the rig. If the battery temperature input is connected to anything when switching to camera-mode for the first time, it'll tell me to change the battery. So it has to be started up then plugged in. Don't want to open it up again just to fix this minor issue (not that I know exactly what's causing it anyway).
Is there any way I could trick the camera into ignoring the battery temp when it goes into shooting mode for the first time?
Quote from: Recyclojunk64 on 03 / March / 2014, 10:29:51Is there any way I could trick the camera into ignoring the battery temp when it goes into shooting mode for the first time?You will probably have to do a lot of reverse engineering / dissassembly to determine where that test is made. I don't think it's part of the current CHDK assembler code FWIW.There is of course a more obvious solution - use a resistance value on the battery input that mimics a normal battery temperature for the remote "off" state. Then short or open that connection for an "on" state.
Does anyone know what the address may be or will I have to use an LED finding script?
// LED table init @ 0xff15b1f0// LED #1: 0xc022c200 (#98 in GPIO table), offset 0x1d8// LED #2: 0xc022c024 (#81 in GPIO table), offset 0xa0
Quote from: Recyclojunk64 on 05 / March / 2014, 10:50:24Does anyone know what the address may be or will I have to use an LED finding script?In platform/sx40hs/sub/100d/stubs_entry.S:Code: [Select]// LED table init @ 0xff15b1f0// LED #1: 0xc022c200 (#98 in GPIO table), offset 0x1d8// LED #2: 0xc022c024 (#81 in GPIO table), offset 0xa0
In platform/sx40hs/sub/100d/stubs_entry.S:Code: [Select]// LED table init @ 0xff15b1f0// LED #1: 0xc022c200 (#98 in GPIO table), offset 0x1d8// LED #2: 0xc022c024 (#81 in GPIO table), offset 0xa0
The magic numbers used to switch on and off that LED are 0x93d800 and 0x83dc00.
There's a "special case" LED @ 0xc022c30c:*(int*)0xc022c30c = ((*(int*)0xc022c30c) & 0xffffffcf) | 0x20 // switch on*(int*)0xc022c30c = (*(int*)0xc022c30c) & 0xffffffcf // switch off
if (kbd_is_key_pressed(KEY_SHOOT_FULL)) { key_pressed = 0; kbd_key_release_all(); return 1; }
void _wait_until_remote_button_is_released(void){ int tick; if ( ( conf.remote_enable ) // menu : USB remote enabled - bracket everything in this function && ( conf.synch_enable ) // menu : Sync enabled - tells us to wait for USB to disconnect && ( usb_sync_wait ) ) // only sync when USB remote is active - don't trap normal shooting { usb_remote_status_led(1); // indicate to user we are waiting for remote button to release - this happens every time the camera takes a picture tick = get_tick_count(); // timestamp so we don't hang here forever if something goes wrong// #ifdef USB_REMOTE_PRECISION_SYNC//if ( conf.synch_vnd_enable )//{ int std_period = _EngDrvRead(GPIO_VSYNC_MAX); int sync_time = std_period * 3; // schedule the end of extended period at t = t(synch pulse) + sync_time if ( conf.remote_input == 0 ) { do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } if ( conf.remote_input == 1 ) { // do { } while( (*(short*)0xc090004a < 300) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); do { } while( (kbd_is_key_pressed(KEY_ZOOM_ASSIST)) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } int cur_cnt = *(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff; // get the counter state at the time of sync int sync_period = sync_time - (std_period - cur_cnt); if (std_period - cur_cnt < 10) { // too close to overflow, wait for the next period sync_period -= std_period; while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}; } *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; while (*(volatile int*)(GPIO_VSYNC_UPDATE)) {}; // wait until the new value is applied //now we are at the beginning of extended period *(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; msleep(40);// #endif//}// Commented out code removed sync_counter++ ; usb_sync_wait = 0 ; usb_remote_status_led(0); // alert the user that we are all done}
Also, I tried it with the zoom assist button without those lines in kbd_process.c and it nearly works, but when the button is released to take the photo (in two-press mode) it doesn't recognise it and instead just times out after 10 seconds. I'm assuming this is because somehow the state of that button can't be properly read during void _wait_until_remote_button_is_released(void), any idea of what could be done to allow it to be read?
FWIW here is the code that's in it.Code: [Select]void _wait_until_remote_button_is_released(void){ int tick; if ( ( conf.remote_enable ) // menu : USB remote enabled - bracket everything in this function && ( conf.synch_enable ) // menu : Sync enabled - tells us to wait for USB to disconnect && ( usb_sync_wait ) ) // only sync when USB remote is active - don't trap normal shooting { usb_remote_status_led(1); // indicate to user we are waiting for remote button to release - this happens every time the camera takes a picture tick = get_tick_count(); // timestamp so we don't hang here forever if something goes wrong// #ifdef USB_REMOTE_PRECISION_SYNC//if ( conf.synch_vnd_enable )//{ int std_period = _EngDrvRead(GPIO_VSYNC_MAX); int sync_time = std_period * 3; // schedule the end of extended period at t = t(synch pulse) + sync_time if ( conf.remote_input == 0 ) { do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } if ( conf.remote_input == 1 ) { // do { } while( (*(short*)0xc090004a < 300) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); do { } while( (kbd_is_key_pressed(KEY_ZOOM_ASSIST)) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } int cur_cnt = *(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff; // get the counter state at the time of sync int sync_period = sync_time - (std_period - cur_cnt); if (std_period - cur_cnt < 10) { // too close to overflow, wait for the next period sync_period -= std_period; while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}; } *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; while (*(volatile int*)(GPIO_VSYNC_UPDATE)) {}; // wait until the new value is applied //now we are at the beginning of extended period *(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; msleep(40);// #endif//}// Commented out code removed sync_counter++ ; usb_sync_wait = 0 ; usb_remote_status_led(0); // alert the user that we are all done}
Started by Sasha Creative Uses of CHDK
Started by vikinggoat General Help and Assistance on using CHDK stable releases
Started by stagdriver Forum related topics (including issues)
Started by Recyclojunk64 « 1 2 ... 5 6 » General Discussion and Assistance
Started by Recyclojunk64 General Discussion and Assistance
