Author Topic: MPU communication  (Read 9627 times)

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #25 on: August 03, 2017, 03:51:28 AM »
Payload of msg 09 14  includes  short integer LensFocusPosition and long integer timing 

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #26 on: August 03, 2017, 04:18:13 AM »
 Lens max aperture , minimum aperture , Lens ID , Wide FocalLength , tele Focal Length ...... are inside msg 03  15

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #27 on: August 04, 2017, 05:29:53 AM »
Any description or info of any Msg is appreciated ,  for example msg 05 02 , msg 09 17 , msg 08 02......

BBA

  • Member
  • ***
  • Posts: 125
Re: MPU communication
« Reply #28 on: August 04, 2017, 12:21:33 PM »
I am interested in your work and would have some questions about your findings (if possible).

JP79dsfr has shared his work on the EF communication protocol between lens and body : cfr http://www.magiclantern.fm/forum/index.php?topic=18308.msg184575#msg184575 .

It is an amazing work that only a passionated specialist could do : Merci beaucoup, JP, pour ce travail incroyable / Many thanks, JP, for this amazing work.

I think the message you are referring to are the same ones as those referenced in his work.

French is my mother language : I have difficulties in english (sometimes 'google traduction' is necessary).

If you have difficulties in french, I can try my best to translate in english some parts of his work as it is quite impressive (pdf : 95 pages).

I think it is best to translate next to the original text and to keep both in parallel.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3040
Re: MPU communication
« Reply #29 on: August 04, 2017, 04:46:48 PM »
it would be cool if you could merge your findings. e.g. in the magic lantern wiki on wikia? http://magiclantern.wikia.com/wiki/
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #30 on: August 07, 2017, 04:02:04 PM »
it would be cool if you could merge your findings. e.g. in the magic lantern wiki on wikia? http://magiclantern.wikia.com/wiki/
So sorry , my english is too bad to writting in  the magic lantern wiki , so many types of msgs as you know .   
however i'll be glad to share my findings here or sending to anyone if he writes info of MPU msgs  in  the magic lantern wiki .

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #31 on: August 23, 2017, 05:23:53 AM »
MPU reports Lens status in Msg09 05 to CPU , 4 bytes in Msg09 05 payload,
the last one is probablly ERCD of Lens communication :
0x00 : good
0x02 : no 0xAA response from Lens after sending Lens CMD 0xA
0x20 : Lens-Camera RTX timeout 
Any info of Msg09 05 on CPU side ?

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #32 on: August 23, 2017, 09:11:46 AM »
I have a couple of messages described on the QEMU branch: extract_init_spells.py. This script parses a startup-log and outputs a header file with the MPU conversation, with comments where the spells are known. Example: 60D.h, 50D.h.

My startup logs used to create the above headers are here (unzip under qemu/startup-logs).

Summary for the hardcoded spells:

- 06 05 06 ARG1 ARG2 00 (MPU -> main CPU): MPU button codes. In bindReceiveSwitch, they are translated into GuiMainTask codes, aka BGMT codes from platform/*/gui.h - see extract_button_codes.py and button_codes.h).

- 06 05 04 00 ARG1 00 (Main CPU -> MPU): NotifyGUIEvent, called by SetGUIRequestMode (used for switching GUI modes, e.g. for going to Canon menu or to PLAY mode). ARG1 is the requested GUI mode. The message is acknowledged by 06 05 04 00 ARG1 01 PROP_GUI_STATE (see NotifyGUIEvent.h); 500D uses ARG1 AA but seems to accept ARG1 01 as well.

From the QEMU thread:
- Detailed description of MPU button codes and GUI modes
- Parameterized MPU spells

Example - entering Canon menu (5D3 1.2.3; 5D3-halfshutter.log):
Code: [Select]
76243> **INT-36h*:000afa38:00:00: *** mpu_recv(06 05 06 00 01 00), from ff2e87f8
7632D>   MainCtrl:ff0cc258:89:03: bindReceiveSwitch (0, 1)
7634B>   MainCtrl:ff0ded40:85:03: GUI_Control:6 0x0                 # 5D3 gui.h: #define BGMT_MENU 6
7676F>    CtrlSrv:ff35d70c:83:03: IDLEHandler PRESS_MENU_BUTTON
767A8>    CtrlSrv:ff18b6e4:83:03: SetGUIRequestMode(2)
767CE>    CtrlSrv:ff0dedc0:83:03: NotifyGUIEvent(1)
78983>    PropMgr:000af9d8:00:00: *** mpu_send(06 05 04 00 01 00), from ff12298c

8004D> **INT-36h*:000afa38:00:00: *** mpu_recv(06 05 04 00 01 01), from ff2e87f8
80208>   MainCtrl:ff146e3c:9c:16: PROP_GUI_STATE 1
80508>    PropMgr:ff0cca34:89:03: GUI_STATE : PLAYMENU

The GUI mode switch can be initiated by the MPU as well. Example: pressing half-shutter while in Canon menu will close the menu first, and afterwards will send the half-shutter event (5D3-halfshutter.log):
Code: [Select]
0DB27> **INT-36h*:000afa38:00:00: *** mpu_recv(06 05 04 00 00 01), from ff2e87f8
0DD57>   MainCtrl:ff146e3c:9c:16: PROP_GUI_STATE 0

13B86> **INT-36h*:000afa38:00:00: *** mpu_recv(06 04 05 00 00), from ff2e87f8
13C2D>   EventMgr:ff208480:8d:03: emDeliverMulticastEvent : SW1ON
13D53>   MainCtrl:ff146348:89:05: EVENTID_METERING_START

316D3> **INT-36h*:000afa38:00:00: *** mpu_recv(06 04 05 0b 00), from ff2e87f8
3173D>   EventMgr:ff2085f8:8d:03: emDeliverMulticastEvent : SW1OFF
31828>   MainCtrl:ff0cd96c:89:05: EVENTID_METERING_TIMER_START



- ?? ?? 0a 08 ... is PD_NotifyOlcInfoChanged (updates shooting info; variable length)

- 06 05 04 01 ARG1 00 (initiated from main CPU, acknowledged by MPU with the same message): PROP_ICU_UILOCK (see UILock.h). Argument is a bit mask of what button groups to lock, see property.h.



On the CPU side, 09 05 appears to trigger PROP_LV_EMD_DRIVE_RESULT; only used in LiveView. Will upload some logs here:

5D3-mirror-up.log
5D3-123-startup-lv1.log
700D-startup.log

Unique entries:
Code: [Select]
5D2:
FD4AC> **INT-36h*:000962c8:00:00: *** mpu_recv(0a 08 09 05 00 80 00 00 00), from ff99f6cc
249A2> **INT-36h*:000962c8:00:00: *** mpu_recv(0a 08 09 05 00 83 00 00 00), from ff99f6cc
58E38> **INT-36h*:000962c8:00:00: *** mpu_recv(0a 08 09 05 00 81 00 00 00), from ff99f6cc

5D3:
F18FA> **INT-36h*:000b0330:00:00: *** mpu_recv(0a 08 09 05 00 00 00 01 00), from ff2e4494
E8FEB> **INT-36h*:000af114:00:00: *** mpu_recv(0a 08 09 05 00 00 00 00 00), from ff2e87f8

EOSM:
**INT-36h*:000dfccc:00:00: *** mpu_recv(0a 08 09 05 01 00 00 00 00), from 1dedc

700D:
**INTERRUP:000c5e3c:00:00: *** mpu_recv(0a 08 09 05 00 00 00 01 00), from ff31af1c

500D:
8680B> **INT-36h*:00092a1c:00:00: *** mpu_recv(0a 08 09 05 00 00 00 01 00), from ff18aa38
EE0F0> **INT-36h*:00092a1c:00:00: *** mpu_recv(0a 08 09 05 00 10 00 00 00), from ff18aa38
AA753> **INT-36h*:00092a1c:00:00: *** mpu_recv(0a 08 09 05 20 00 00 00 00), from ff18aa38

dfort

  • Hero Member
  • *****
  • Posts: 1974
Re: MPU communication
« Reply #33 on: August 23, 2017, 03:20:58 PM »
The links to the log files are broken.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #34 on: August 23, 2017, 06:18:17 PM »
Solved.

Next, I'd like to show some (recent) techniques for checking what these MPU messages are for. Of course, the first step would be to look at mpu_send and mpu_recv (stubs available on the dm-spy-experiments branch on some models, but I'm thinking to make them available everywhere). However, these functions are pretty generic.

The first thing you can do is to look up the MPU message in the logs, and then examine the nearby messages. Things are made difficult by the multitasking environment; furthermore, MPU functionality is often delegated to or from other tasks.

For mpu_send (from main CPU to MPU), you could check the caller (reported in the dm-spy logs as LR), or the full stack trace. There are a couple of approaches:
- compile ML with debug information (-ggdb3), then run it under QEMU+GDB (example).
- in QEMU you also have the option to use -d callstack or -d calls.
- on the camera, you can also get a limited stack trace (call backtrace_getstr from the mpu_send hook in the dm-spy-experiments branch).

Many mpu_recv calls are followed by msg_queue_send. Tracing these calls and matching them with the corresponding msg_queue_recv from other tasks is helpful.

Todo: some examples.

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #35 on: August 29, 2017, 10:26:39 AM »
@a1ex , some decodings in 550D MPU FW :
Msg 06 01 = Display
Msg 06 03 = Play
Msg 06 04 = EraseButton
Msg 06 0A = AE_Lock
Msg 06 0C = Set button
Msg 06 11 = LockSW
Msg 06 12 = CardCover
Msg 06 13 = BatCover
Msg 06 18 = CrossUp
Msg 06 19 = CrossDown
Msg 06 1A = CrossRight
Msg 06 1B = CrossLeft
Msg 06 1C = AVbutton
Msg 06 1E is strongly related to mestimer starting
Msg 06 21 = RECstart

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #36 on: August 29, 2017, 12:34:25 PM »
They seem to match (QEMU button_codes.h):

Code: [Select]
static int button_codes_550D[] = {
    [BGMT_INFO]                         = 0x0101,
    [BGMT_LV]                           = 0x2101,
    [BGMT_MENU]                         = 0x0001,
    [BGMT_PLAY]                         = 0x0301,
    [BGMT_PRESS_DOWN]                   = 0x1901,
    [BGMT_PRESS_LEFT]                   = 0x1B01,
    [BGMT_PRESS_RIGHT]                  = 0x1A01,
    [BGMT_PRESS_SET]                    = 0x0C01,
    [BGMT_PRESS_UP]                     = 0x1801,
    [BGMT_PRESS_ZOOM_IN]                = 0x0901,
    [BGMT_PRESS_ZOOM_OUT]               = 0x0A01,
    [BGMT_Q]                            = 0x0201,
    [BGMT_Q_ALT]                        = 0x0501,
    [BGMT_TRASH]                        = 0x0401,
    [BGMT_UNPRESS_DOWN]                 = 0x1900,
    [BGMT_UNPRESS_LEFT]                 = 0x1B00,
    [BGMT_UNPRESS_RIGHT]                = 0x1A00,
    [BGMT_UNPRESS_SET]                  = 0x0C00,
    [BGMT_UNPRESS_UP]                   = 0x1800,
    [BGMT_UNPRESS_ZOOM_IN]              = 0x0900,
    [BGMT_UNPRESS_ZOOM_OUT]             = 0x0A00,
    [BGMT_WHEEL_DOWN]                   = 0x0E01,
    [BGMT_WHEEL_LEFT]                   = 0x0DFF,
    [BGMT_WHEEL_RIGHT]                  = 0x0D01,
    [BGMT_WHEEL_UP]                     = 0x0EFF,
    [GMT_GUICMD_OPEN_BATT_COVER]        = 0x1301,
    [GMT_GUICMD_OPEN_SLOT_COVER]        = 0x1201,
    [GMT_GUICMD_START_AS_CHECK]         = 0x1100,
};

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #37 on: August 31, 2017, 12:33:48 PM »
Here's how the full shutter event looks like:

Code: [Select]
971C5> **INT-36h*:000afcec:00:00: *** mpu_recv(06 05 03 54 00 00), from ff2e87f8
97204> **INT-36h*:000afaf0:00:00: *** TryPostEvent(PropMgr, 0xa, 0x71c7f0, 0x14), from ff123cf8
97292> **INT-50h*:ff13b96c:00:01: [PM] DisablePowerSave (Counter = 3)
972B8> **INT-50h*:ff13b9dc:00:01: [PM] EnablePowerSave (Counter = 2)

97320> **INT-36h*:000afcec:00:00: *** mpu_recv(06 04 05 01 00), from ff2e87f8
97355> **INT-36h*:000afaf0:00:00: *** TryPostEvent(EventMgr, 0x2, 0x1, 0x712e98), from ff0f5308
973E5> **INT-50h*:ff13b96c:00:01: [PM] DisablePowerSave (Counter = 3)
9740D> **INT-50h*:ff13b9dc:00:01: [PM] EnablePowerSave (Counter = 2)

97476> **INT-36h*:000afcec:00:00: *** mpu_recv(06 04 05 0e 00), from ff2e87f8
974A8> **INT-36h*:000afaf0:00:00: *** TryPostEvent(EventMgr, 0x2, 0xe, 0x712f2c), from ff0f5308
974E9>   EventMgr:000afaf0:00:00: *** TryPostStageEvent(Fstorage, 0x9, 0x712e98, 0x0), from ff0e06b8
9752A>   EventMgr:000afaf0:00:00: *** TryPostStageEvent(ShootCapture, 0x11, 0x0, 0x0), from ff0dab30
97585>   EventMgr:000afaf0:00:00: *** TryPostEvent(Gmt, 0x15, 0x1, 0x0), from ff174510
975D9>   EventMgr:ff208818:8d:03: emDeliverMulticastEvent (ID = 14)
97615>   EventMgr:000afaf0:00:00: *** TryPostEvent(RscMgr, 0xc, 0x712f2c, 0x0), from ff0ed1b4
97656>   EventMgr:000afaf0:00:00: *** TryPostStageEvent(ShootCapture, 0x1, 0x0, 0x0), from ff0dad98
976E8> **INT-50h*:ff13b96c:00:01: [PM] DisablePowerSave (Counter = 3)
97716> **INT-50h*:ff13b9dc:00:01: [PM] EnablePowerSave (Counter = 2)
97749> ShootCaptu:ff14b98c:93:03: scsReleaseOn
9779D> ShootCaptu:ff147918:93:03: scsReleaseStart

This also shows how the MPU events are dispatched to other tasks; would be nice to draw it somehow.

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #38 on: September 08, 2017, 05:12:01 PM »
@a1ex , event of SW1 and SW2 in 550D MPU FW are not sent in Msg 06  ,
i guess they are strongly related to half shutter and full shutter pressing ,
i'm going to check how they work .

@a1ex , LensIDs are described in Canon Exif Tags  https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html
do you know , in which kind of MPU Msg , LensID mentioned above is sent to CPU ?   



 

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #39 on: September 08, 2017, 09:57:24 PM »
Yes, SW1 and SW2 are not like regular button events. Currently I emulate SW1 (half-shutter) like this:

Code: [Select]
0x06, 0x05, 0x06, 0x26, 0x01, 0x00 (COM_SW_SOMETHING / GUICMD_PRESS_BUTTON_SOMETHING, valid on 60D and newer models, not sure what it does)
0x06, 0x04, 0x05, 0x00, 0x00, 0x00 (press)
0x06, 0x04, 0x05, 0x0B, 0x00, 0x00 (unpress)

This does trigger the SW1 property and I remember it even changed something on the exposure indicator, but it doesn't get out of Canon dialogs (e.g. if pressing half-shutter while in Canon menu).

For LensID, the 500D startup log from the archive in my previous post was taken with a 24/2.8 STM, and its info gets displayed on QEMU. Not sure which are the messages that actually contain the lens info - will brute-force them later.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #40 on: September 18, 2017, 10:33:45 PM »
06 05 01 00 MODE 00: change shooting mode (PROP_SHOOTING_MODE).

06 05 06 1c 01 00 / 06 05 06 1c 00 00: possibly Av press/unpress
- 500D: not forwarded to GuiMainTask, but followed by bindReceiveNewTFTOLC; see BGMT_AV in 1100D gui.h
- 100D: same MPU button code, but forwarded to GuiMainTask like all other buttons.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #41 on: October 01, 2017, 02:22:47 PM »
On EOS-550D ,TX19a  may send the following msg to main CPU :
Code: [Select]
char msg[] = { 0x04, 0x05, 0x00, 0x00 };  // ae start
char msg[] = { 0x04, 0x05, 0x01, 0x00 };  // rel start
char msg[] = { 0x04, 0x05, 0x05, 0x00 };  // rel end , or bulb end
char msg[] = { 0x04, 0x05, 0x06, 0x00 };  // rel cancel
char msg[] = { 0x04, 0x05, 0x07, 0x00 };  // ae stop
char msg[] = { 0x04, 0x05, 0x0B, 0x00 };  // ae timer start
char msg[] = { 0x04, 0x05, 0x0E, 0x00 };  // related to rel
char msg[] = { 0x04, 0x05, 0x0F, 0x00 };  // related to rel

These match the messages I've been using for half-shutter emulation :)

On my logs, "release end" aka SW2OFF appears to be 06 04 05 04 00.

06 04 05 01 00 is probably "release on" (scsReleaseOn) and 06 04 05 0e 00 is probably "release start" (scsReleaseStart).

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10326
  • 5D Mark Free
Re: MPU communication
« Reply #42 on: October 08, 2017, 12:48:23 AM »
do you know , in which kind of MPU Msg , LensID mentioned above is sent to CPU ?   

Just found out:

Code: [Select]
    "03 15"  :   ("PROP_LENS",),
    "03 24"  :   ("PROP_LENS_NAME",),

example:
Code: [Select]
        { 0x24, 0x23, 0x03, 0x15, 0x01, 0x20, 0x50, 0x10, 0x3a, 0x00, 0x18, 0x00, 0x18, 0x81, 0x47, 0x92, 0x7e, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0xf1, 0x82, 0x01, 0x00, 0x02, 0x07, 0x21, 0x00, 0x00 },/* reply #12.9 */
        { 0x18, 0x17, 0x03, 0x24, 0x45, 0x46, 0x2d, 0x53, 0x32, 0x34, 0x6d, 0x6d, 0x20, 0x66, 0x2f, 0x32, 0x2e, 0x38, 0x20, 0x53, 0x54, 0x4d, 0x00, 0x00 },/* reply #12.3 */

(see PROP_LENS in lens.c for decoding)

Also collected most of the spells into extract_init_spells.py (also exported to known_spells.h)

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #43 on: October 10, 2017, 06:39:59 AM »
@a1ex ,
MPU reports Lens status in Msg09 05 to CPU , 4 bytes in Msg09 05 payload,
the last one is probablly ERCD of Lens communication :
0x00 : good
0x02 : no 0xAA response from Lens after sending Lens CMD 0xA
0x20 : Lens-Camera RTX timeout 
Any info of Msg09 05 on CPU side ?

EDIT :
0x1 looks like that lens is detached.
0x80 is very special , maybe Lens in debug mode.

leegong

  • New to the forum
  • *
  • Posts: 22
Re: MPU communication
« Reply #44 on: October 10, 2017, 08:25:11 AM »
@a1ex ,
Data payload inside Msg09 02 is same as that of Msg09 05 , status of AF , Aperture
and IS (motor) in Lens and  ERCD of Lens communication.
Msg09 0A is strongly related to "lv ae".
Msg05 02 is "release data"
Msg05 03 is "release after data"
Msg05 05 is "bulb end"