G7X battery 4th terminal for communication

reyalp

13502

Re: G7X battery 4th terminal for communication

« Reply #10 on: 02 / May / 2021, 16:56:40 »

Advertisements

Quote from: Recyclojunk64 on 02 / May / 2021, 11:10:45

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).

Quote

CreateController hooks below in case they are helpful to anyone else (addresses correct for g7x2 110b)

Thanks for posting the code.

Quote

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.

Logged

Don't forget what the H stands for.

Recyclojunk64

Re: G7X battery 4th terminal for communication

« Reply #11 on: 27 / September / 2021, 08:53:24 »

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

« Last Edit: 28 / September / 2021, 09:23:33 by Recyclojunk64 »

Logged

reyalp

13502

Re: G7X battery 4th terminal for communication

« Reply #12 on: 27 / September / 2021, 13:17:24 »

Quote from: Recyclojunk64 on 27 / September / 2021, 08:53:24

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.

Quote

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.

Quote

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.

Logged

Don't forget what the H stands for.

Recyclojunk64

Re: G7X battery 4th terminal for communication

« Reply #13 on: 03 / October / 2021, 09:56:40 »

Quote from: reyalp on 27 / September / 2021, 13:17:24

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.

Quote

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):

Code: [Select]

            "    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)

Code: [Select]

            "    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).

Logged