CHDK Forum
Canon DSLR Development (+ other development) => Hotwire! Hardware Mods, Accessories and Insights => Topic started by: Recyclojunk64 on 28 / December / 2020, 09:22:04
-
Hi all,
So I've noticed that the batteries for my G7X cameras have 4 terminals instead of 3. Applying a piece of tape over this it gives a battery communication error indicating that there is some communication going on between the camera and battery over this terminal. If this could be used as a serial input/output terminal it could be very useful for many things such as for my StereoSync project https://chdk.setepontos.com/index.php?topic=14195 (https://chdk.setepontos.com/index.php?topic=14195)
I did some searching on this forum all I came across was this post: https://chdk.setepontos.com/index.php?topic=13451.msg137584#msg137584 (https://chdk.setepontos.com/index.php?topic=13451.msg137584#msg137584)
Unfortunately my digital oscilloscope is currently broken so I just probed them with my analog scope for now, the result is attached. Scale is 0.1ms and 2V
Each bit is about 20us in length. The camera seems to transmit many packets (with different bits each time) for about a second before displaying the battery communication error.
I will try and borrow a digital oscilloscope soon or set it up with a logic analyzer to see what communication is going on here. Perhaps it could be 1-Wire serial protocol?
Any ideas of how to go about reading and writing to this pin with CHDK?
-
You can find various things related to the the battery authentication in the the firmware (the string are relatively obvious), but it's an area we've mostly avoided for reasons discussed here https://chdk.setepontos.com/index.php?topic=12542.msg130630#msg130630 I believe third party sellers have now widely bypassed the battery validation for that generation of camera, so possibly less relevant now.
Note on some cameras at least one battery related task runs on the Omar core: https://chdk.setepontos.com/index.php?topic=11316.msg142038#msg142038
I'm not clear why you need this rather than one of the existing inputs, I guess you're expecting / hoping for some kind of 2 way communication? FWIW, on g7x you should be able to do that with HDMI power control and hot plug detect. Alternately, the HDMI interface also includes i2c if you want to reverse engineer that. I'd expect that to be a lot of work to repurpose for general communication, but it would be broadly useful and potentially applicable to many cameras if you figured it out.
Or you could include a pi zero in your rig and control it all with PTP :)
-
Thanks, yep after 2 way communication. I started looking into this before I found out about the HDMI power control output which could also work. I guess the advantage of this is that everything is nicely self contained into a dummy battery without cables plugged into the side (which would force the cameras to be spaced out more depending on how small the HDMI connector is). And the bitrate will be faster and more reliable as it is presumably a proper serial port rather than bitbanging with interrupts as with the HDMI power control and hot plug detect (or what I was doing before with the battery temp terminal and AF LED).
However the disadvantage is that only a few cameras have this 4th terminal, whereas all of the non-ancient ones have mini/micro HDMI. Do you know if the HDMI power control output and the hot plug detect input can work on all of the HDMI cameras or only the newer ones? If it can also work for S100 and S110 then that would make this a more attractive option than putting in the work to get the battery 4th terminal communication working but only being able to use it on the G7X and M series cameras.
HDMI I2C sounds like a good idea I will have a look into that and start another thread if make any progress with it.
As for PTP it could possibly work as well if I used another input for syncing the shutters, though the HDMI does sound like a better idea at this point.
-
Do you know if the HDMI power control output and the hot plug detect input can work on all of the HDMI cameras or only the newer ones?
Not all cameras are able to control the HDMI power out. Those with CAM_REMOTE_HDMI_POWER_OVERRIDE definitely can, but most models haven't been tested, and we don't currently have an automated way to detect which ones can. Some discussion of models which are known to be able to do it or not in
https://chdk.setepontos.com/index.php?topic=13451.msg139364#msg139364
https://chdk.setepontos.com/index.php?topic=13451.msg139575#msg139575
If it can also work for S100 and S110 then that would make this a more attractive option than putting in the work to get the battery 4th terminal communication working but only being able to use it on the G7X and M series cameras.
From the thread above s110 doesn't seem to have HDMI power control, at least not with the simply named function that we use on the other cameras
Note CAM_REMOTE_HDMI_POWER_OVERRIDE doesn't directly refer to the ability to control HDMI power: These cameras turn off HDMI power in rec mode, so need it forced on to use HPD remote. However, there could be cameras which can control the power but don't automatically turn it off in rec.
As for PTP it could possibly work as well if I used another input for syncing the shutters, though the HDMI does sound like a better idea at this point.
You can do both PTP and hardware remote trigger on USB with usb_force_active (https://chdk.fandom.com/wiki/Lua/PTP_Scripting#usb_force_active) and a custom cable but having them separate is certainly simpler.
One other caution: The latency of the non-USB inputs has not been tested that I know of. I'd guess analog AV is likely similar to USB, since it's likely just a simple GPIO, but it requires a much trickier custom connector. HDMI stuff is potentially a lot more complicated, since my impression is the entire HDMI interface is controlled over i2c.
-
One other caution: The latency of the non-USB inputs has not been tested that I know of. I'd guess analog AV is likely similar to USB, since it's likely just a simple GPIO, but it requires a much trickier custom connector. HDMI stuff is potentially a lot more complicated, since my impression is the entire HDMI interface is controlled over i2c.
If there are latency issues with the HDMI power out then that would be a problem. I will do some experimentation with this once I get a micro HDMI connector for it but doesn't sound very promising at the moment. Especially if it does not work with the S110 cameras as well.
The HDMI I2C option looks the most appealing at the moment especially with its other use cases, I might have a go at getting the I2C output working on one of my old S100 cameras in case I brick it and if it works hopefully the I2C functions will be similar to the G7X camera.
-
Looks like the I2C on the HDMI connector is done through the HDMI chip, at least for the S100 camera which has an ADV7521NK chip. So it's probably not as straightforward as I was hoping.
According to https://www.analog.com/en/products/adv7521nk.html#product-overview the I2C is done with "On-chip MPU w/ I2C® master performs EDID reading operations" so this would require not only hacking the I2C going to this chip but also getting the on chip MPU here to forward other packets to it's I2C master. Even if possible it might still have latency issues.
I haven't checked what HDMI chip the G7X has in it, I just took the back cover off and it looks like much more disassembly is required to access the mainboard. Even if it is different then that would mean that the same solution is not likely applicable to all HDMI cameras.
Looks like my best options are the HDMI power output if I measure the latency low enough, the battery 4th terminal which I will probably have a go at, or the fall back is a Pi Zero with PTP and a low latency input.
-
AF LED
This is what i'm doing to control an external device. Is not very reliable.
Unfortunately, my cameras do not support HDMI control.
I still hope for another solution....
-
Edit: Now using a G7X Mark II for testing from here on (updated to 110b firmware)
I've done some tests with the HDMI 5V out, including modifying some of the assembly code for the low level functions that control the HDMI power out. Results were unusual, seems like there is both control of the DC-DC converter and maybe something that shorts the output as well for faster response. However I could not get a rise time of less than 4ms and fall time of less than 1ms (but sometimes much slower) which will be unsuitable for SteroSync communication. I'll probably make a separate thread for this with the results and scope screenshots in case it is useful later on.
HDMI I2C and CEC I think will be difficult to reverse engineer (and not sure if even possible as they are probably handled by the HDMI IC) but I will likely revisit them also later on when I get more time and have more knowledge about the firmware and SRE in general. My goal is to have StereoSync work with multiple communication methods which can be selected depending upon what the camera supports and what the user wants.
For now though I've moved back on to trying to get the battery 4th terminal working for communication, since I think it is more likely to be achievable than anything on HDMI and more reliable and elegant than CHDKPTP with a Raspi 0 and USB hubs. My stereo rig will be using external batteries and so I will need to disable the battery warning message anyway the G7X mk II still gives the message with the temp sensor terminal covered unlike the G7X mk I), I could probably could have it display the warning to the user just once and then remember the result or something like that, or maybe make it work like the G7X mk I. Just for now I have disabled it by overwriting the result of a function that checks if the camera has had the battery replaced since last startup.
I have found many interesting functions that are called with CreateController_FW. I couldn't find any info on the forum or wiki about this, or any uses in the CHDK source. Is there any knowledge about it? And what would be the best way to modify a function called with this? I could possibly copy the hook system for CreateTask in boot.c and patch CreateController_FW to create the hooks similarly, or I could start from task_Startup and modify each function working its way down until the CreateController_FW is called and have it load the modified function instead?
-
Just for now I have disabled it by overwriting the result of a function that checks if the camera has had the battery replaced since last startup.
FWIW, there are some logical events related to this, search for "Bat" in the levent table.
I have found many interesting functions that are called with CreateController_FW.
Funny, I was just recently digging in this area and thinking about writing some of it up. Some related information in https://chdk.setepontos.com/index.php?topic=13522.20 and https://chdk.setepontos.com/index.php?topic=6560.msg104282#msg104282
Basics:
A "controller" is a function that receives events (from PostLogicalEventToUI etc). Controllers have a "z order" so (probably) the one on top sees events first and the return value determines whether the ones further up the stack see it. The event ID is in r1.
The events 0x800 - 0x803 seem related to creation / destruction / z order changes
I recently added some ghidra scripts which will label levent related calls for you (though not yet event IDs in controller functions) https://chdk.setepontos.com/index.php?topic=13718.msg145519#msg145519
One potentially very useful thing about controllers is they are allocated from UI memory (see https://chdk.setepontos.com/index.php?topic=11246.0)
On modern cameras (around dryos r43 and later) UI memory is allocated and freed through function pointers in the firmware data segment (factory mode sets this to just be malloc / free instead of using a separate pool).
This means it should be relatively straightforward to hook the UI memory malloc function, check if the LR is in CreateController, and if so jump to your own version of create controller that installs a custom controller. Or to log when /where specific controllers are created.
The controller structure varies by camera (including within the same dryos version >:() but the first element appears to always be the function pointer.
edit:
I could possibly copy the hook system for CreateTask in boot.c and patch CreateController_FW to create the hooks similarly
See a above for a possible method of hooking. You can't follow the approach from CreateTask because CreateController_FW is in ROM. You could use cache hacks (https://chdk.setepontos.com/index.php?topic=9217.10) (some examples in https://chdk.setepontos.com/index.php?topic=14052.msg145308#msg145308)
You could also modify the controller structures in memory after they are created.
-
Thanks for the explanations, I have dug through the firmware a bit more and tried some more things, including hooking the controller functions, though I haven't had success yet with getting output on the 4th terminal but I haven't given up hope just yet.
The Ghidra scripts have been pretty helpful thanks, I've been updating from SVN and running new ones as they appear except for the MZRM ones which I still need to generate the handler list for first if I need to look into the Zico core which I guess is just for the GPU so probably not at this stage.
I got the controller functions hooked through a custom ui_mallloc function which runs a custom CreateController function that hooks the desired controller functions as suggested. It does work to modify the controller functions (tested by illuminating the AF LED) and has been useful for testing what sections of different controller functions do by skipping those sections and seeing what happens. CreateController hooks below in case they are helpful to anyone else (addresses correct for g7x2 110b)
void __attribute__((naked,noinline)) task_Startup_my() {
asm volatile (
...
" bl sub_e0425886\n" // various initilizations including for ui_malloc
// ui_malloc hook
" ldr r4, =0x0000cb64\n" // +
" ldr r0, =ui_malloc_default_my\n" // +
" str r0, [r4, #4]\n" // +
" bl sub_e005b33e_my\n" // -> taskcreate_physw
...
);
}
...
//0xe0371e68
void __attribute__((naked,noinline)) ui_malloc_default_my() {
asm volatile(
// hooks first, r1 input is not used in ui_malloc_default
// hook CreateController function
" ldr r1, =CreateController+0x1c\n" // + function to hook + offset in fuction where lr will be (just after ui_malloc)
" cmp r1, lr\n" // + check if ui_malloc has been called from the function to hook
" beq CreateController_my\n" // + return immediately to alternative function
//capdis -f=chdk -s=0xe0371e69 -e=0xe0371ea9 -stubs PRIMARY.BIN 0xe0000000
" push {r3, r4, r5, r6, r7, lr}\n"
" mov r6, r0\n"
" ldr r5, =0x0000cb64\n"
" ldrb r0, [r5]\n"
" lsls r0, r0, #0x1f\n"
" beq loc_e0371e7e\n"
" movs r2, #0x6c\n"
" movs r0, #0\n"
" ldr r1, =0xe0371f18\n" // *"UiMemory.c"
" bl sub_dffc96f4\n"
"loc_e0371e7e:\n"
" ldr r0, [r5]\n"
" mov r1, r6\n"
" bl sub_e037e604\n"
" movs r4, r0\n"
" bne loc_e0371ea6\n"
" ldr r0, [r5]\n"
" mov r1, sp\n"
" bl sub_e037e60c\n"
" ldr r2, [sp]\n"
" mov r1, r6\n"
" ldr r0, =0xe0371f24\n" // *"Size: %ld, MaxRegion: %ld\n"
" bl sub_e037e664\n"
" movs r2, #0x71\n"
" movs r0, #0\n"
" ldr r1, =0xe0371f18\n" // *"UiMemory.c"
" bl sub_dffc96f4\n"
"loc_e0371ea6:\n"
" mov r0, r4\n"
" pop {r3, r4, r5, r6, r7, pc}\n"
);
}
//0xe0371490
void __attribute__((naked,noinline)) CreateController_my() {
asm volatile(
//capdis -f=chdk -s=0xe0371491 -e=0xe0371515 -stubs PRIMARY.BIN 0xe0000000
// " push.w {r4, r5, r6, r7, r8, lr}\n" // - already done from original CreateController function
// " mov r7, r0\n" // -
// " ldr r5, =0x0000c518\n" // -
// " movs r6, #0\n" // -
// " mov r8, r1\n" // -
// " ldrb r0, [r5]\n" // -
// " lsls r0, r0, #0x1f\n" // -
// " beq loc_e03714a6\n" // -
// hook BattAuthController function
" ldr r0, =BattAuthController\n" // + controller function to hook
" cmp r0, r7\n" // + check if we are creating that controller here
" it eq\n" // + EQ block
" ldreq r7, =BattAuthController_my\n" // + alternate controller function to create instead
// " beq loc_e03714a6\n" // + continue at ui_malloc
//hook more controller functions here simmilarly
" b loc_e03714a6\n" // + continue at ui_malloc (replaces beq from above)
"loc_e03714a2:\n"
" movs r0, #0x11\n"
" b loc_e037134a\n" // return
"loc_e03714a6:\n"
" movs r0, #0x28\n"
" bl sub_e0371f08\n" // ui_malloc
" ldr r1, =0x0001d4c0\n"
" mov r4, r0\n"
" ldr r0, [r5]\n"
" mov.w r3, #0x288\n"
" ldr r2, =0xe037173c\n" // *"CtrlMan.c"
" bl sub_dffca338\n"
" cbz r0, loc_e03714c6\n"
" mov r0, r4\n"
" bl sub_e0371f0e\n"
" b loc_e03714a2\n"
"loc_e03714c6:\n"
" ldr r0, [r5, #0xc]\n"
" cbz r0, loc_e03714cc\n"
" mov r6, r0\n"
"loc_e03714cc:\n"
" str r7, [r4]\n"
" strd r8, r0, [r4, #4]\n"
" movs r0, #0x19\n"
" str r0, [r4, #0xc]\n"
" movs r1, #0x19\n"
" ldr r0, [r5, #0x14]\n"
" str r0, [r4, #0x10]\n"
" movs r0, #0\n"
" str r0, [r4, #0x18]\n"
" str r0, [r4, #0x1c]\n"
" str r0, [r4, #0x20]\n"
" ldr r0, [r5, #0x1c]\n"
" str r0, [r4, #0x24]\n"
" adds r0, r0, #1\n"
" str r0, [r5, #0x1c]\n"
" ldr r0, =0xe03713bd\n"
" str r0, [r4, #0x14]\n"
" mov r0, r4\n"
" bl sub_e03713f4\n"
" ldr r0, [r5]\n"
" bl sub_dffcad46\n"
" movs r3, #0\n"
" movw r1, #0x803\n"
" mov r2, r3\n"
" mov r0, r4\n"
" bl sub_e0371330\n"
" mov r1, r4\n"
" mov r0, r6\n"
" bl sub_e03719b8\n"
" mov r0, r4\n"
// " b loc_e037134a\n" // - return (right below now rather than very far above)
//capdis -f=chdk -s=0xe037134b -c=1 -stubs PRIMARY.BIN 0xe0000000
"loc_e037134a:\n"
" pop.w {r4, r5, r6, r7, r8, pc}\n"
);
}
I also came across some strings just now in the firmware starting with N5fluid, any idea what that might refer to? Such as "N5fluid12Battery_baseE" and "N5fluid16FL_TimerReceiverE"
-
The Ghidra scripts have been pretty helpful thanks, I've been updating from SVN and running new ones as they appear except for the MZRM ones which I still need to generate the handler list for first if I need to look into the Zico core which I guess is just for the GPU so probably not at this stage.
Yes, it's just for the GPU, and most of Zico functions are not used (It seems Canon has a standard library for Zico, but the cameras only use a small part of it).
CreateController hooks below in case they are helpful to anyone else (addresses correct for g7x2 110b)
Thanks for posting the code.
I also came across some strings just now in the firmware starting with N5fluid, any idea what that might refer to? Such as "N5fluid12Battery_baseE" and "N5fluid16FL_TimerReceiverE"
I hadn't noticed that one before. It seems to be new in digic 7. From the strings, N5fluid looks like some kind of user interface / widget library, but what parts of UI it handles and how it differs from the earlier cams isn't obvious to me. N5fluid14FJedi* probably has some connection to the GPU, is "Jedi" appears there too.
There are also a few references to "FLUiD" like "FLUiDMan_Start" which suggest some kind of subsystem.
-
Been busy for a bit with other projects, but back onto the StereoSync project again recently.
Some findings so far (g7x2 110b):
sub_e0470642 will set it to transmit mode, where the output pullup impedance is lower (or maybe driven high) and transmission is possible (any signal sent from the battery will not pull it down all the way to zero volts in this state).
sub_e04f1076 will set it to receive mode, where the output pullup impedance is lower and receiving signals from the battery is possible.
sub_e04f0fe8 will force the signal low with r0=0, not forced low with r0=1. This is used for long sync pulses from the camera to the battery.
sub_e04f0ffa will transmit a byte (value of r0), with 20us per bit and a delay of 1200us afterwards (likely for syncing each the start of each byte). There is 1 low bit for sync then 8 bits MSB-first, 1 is high, 0 is low.
Modifying this function to skip the 1200us delay is possible (it's just a call to UTimer function) and does not seem to cause any issues. Not sure yet how it actually transmits the byte, it looks like it writes it to an MMIO address DAT_c0800000 (plus maybe an offset). Edit: it writes the inverted byte to 0xc0810000 (measured), and makes some other MMIO writes probably to configure the transmission
sub_e04f1076 starts before the battery transmits its return message, and finishes once that message is done. How it receives the transmision is not clear yet. One of its sub functions mentions "NRTable.c" any ideas what that may be?
Another thing I found was a postman_mm function, that seems to run once from the InitExDrivers function, I'm thinking that this may have some relevance as well. Perhaps a postman_mm function runs in the background (maybe on the Omar core) and collects received data then passes it back to the BA_ function.
It would probably be useful for me to look at the code running on the Omar core that is initialized from the InitExDrivers function, however the Omar core isn't mentioned in in stubs_entry.S, and in a strings search it is only mentioned once in the firmware at "e0cb62c4 GIC_OmarIntc" so I'm not sure where the DryOS for that is, any idea of how to find it? If the Omar core still exists for Digic7?
Thanks
-
sub_e04f1076 starts before the battery transmits its return message, and finishes once that message is done. How it receives the transmision is not clear yet. One of its sub functions mentions "NRTable.c" any ideas what that may be?
I always thought NRTable was related noise reduction. That could be wrong, but it's been around since the earliest firmware and shows up a lot in shooting related functions.
Another thing I found was a postman_mm function, that seems to run once from the InitExDrivers function, I'm thinking that this may have some relevance as well. Perhaps a postman_mm function runs in the background (maybe on the Omar core) and collects received data then passes it back to the BA_ function.
I'd agree postman is likely related to inter-processor communication.
It would probably be useful for me to look at the code running on the Omar core that is initialized from the InitExDrivers function, however the Omar core isn't mentioned in in stubs_entry.S, and in a strings search it is only mentioned once in the firmware at "e0cb62c4 GIC_OmarIntc" so I'm not sure where the DryOS for that is, any idea of how to find it? If the Omar core still exists for Digic7?
AFAIK Digic 7 does not have Omar. It does have "Lime" which is apparently an xtensa core that handles a lot of the networking stuff. Given that the main processor has two cores, it also wouldn't be surprising if some of the stuff previously on Omar is now in the main firmware.
-
I always thought NRTable was related noise reduction. That could be wrong, but it's been around since the earliest firmware and shows up a lot in shooting related functions.
Yeah that makes sense based on the string NRTable perhaps meaning Noise Reduction Table. But weird that that string also shows up inside a function (0xe005ea88) that is called from the data receiving function, and also called from dry_error_printf, RegisterInterruptHandler, and CancelHPTimer. I'm not sure how the DebugAssert .c strings are placed there by Canon but maybe it means they just had an unrelated low-level function within their NRTable.c file? I'm going to investigate this function in more detail to see what it actually does though.
It does have "Lime" which is apparently an xtensa core that handles a lot of the networking stuff.
Thanks I will also look into that, a search for "Lime" on Ghidra did find many interesting things.
For now though there has been success! I have been able to send data from one camera to another through the battery authentication terminal using no external hardware just the terminals wired together (and the GND terminals connected). This is by calling the built-in functions that send and receive data. I've dug into the sending function and will writeup how that works later (works directly with MMIO's, addresses are known) whereas I haven't fully understood how the receiving function works yet at the low level. But for now being able to use the built-in functions or modified versions of them is good enough.
Example of sending function call (g7x2 110b):
" bl sub_e0470642\n" //Set transmission mode
" mov r0, #0x1\n" //mmio_select, usually 0x1
" ldr r1, =message_to_send\n" //data to write, is sent LSB first
" mov r2, #5\n" //size of data to send in bytes, should be 1 higher for some reason otherwise last byte isn't sent
" mov r3, sp\n" //address to store number of bytes to be sent, usually SP
" bl sub_e045b2de\n" //send_transmission
" bl sub_e047065e\n" //set receive mode
Example of receiving function call (must be called through _create_task as it hangs untill it gets data)
" mov r0, #0x1\n" //mmio_select, usually 0x1
" ldr r1, =message_receive_buffer\n" //where to write the received data
" mov r2, #4\n" //number of bytes to receive
" add r3, sp, #0x4\n" //something gets written to the stack not sure what
" bl sub_e045b266\n" //receive_transmission
The input arguments are pretty similar for both functions. In the battery authentication function they are only ever called to send or receive one byte at a time, but they work fine sending multiple bytes.
Looking at the signal on the digital scope it looks like a 8E2 serial protocol with 20us/bit. 1 low start bit, 8 data bits, 1 parity bit, 2 stop bits, then sometimes half a bit variable delay (10us) before the next byte is transmitted. Should be possible to also interface with a microcontroller such as an Arduino through this.
Interestingly sending extra data before calling the receiving function buffers that data, and sometimes that buffered data remains even between powerdowns.
One more thing I will do is potentially modify the receiving function it to accept a variable length of data which looks pretty straighforward. I will have to decide on how to structure the transmissions though. Either some sort of EOL character (and then being limited on what data can be sent, binary data will be a problem) or maybe having the first byte indicate how many following bytes there will be (which may be unreliable if it ever gets out of sync).