There was some progress understanding the communication between the main CPU and the MPU (a secondary CPU that controls buttons, lens communication, shutter actuation, viewfinder and others), so I think it's time to open a new thread.
Resources:
* QEMU docs: MPU Communication (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-mpu-communication)
* http://magiclantern.wikia.com/wiki/Tx19a
* Code to dump MPU firmware: modules/mpu_dump (https://bitbucket.org/hudson/magic-lantern/src/unified/modules/mpu_dump/)
* NikonHacker emulator for TX19A: http://magiclantern.fm/forum/index.php?topic=3467.msg91186#msg91186
* Communication protocol emulated in QEMU: qemu/eos/mpu.c (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu.c)
* How to log the MPU messages: [1] (http://magiclantern.fm/forum/index.php?topic=2864.msg166938#msg166938) [2] (http://www.magiclantern.fm/forum/index.php?topic=2388.msg113154#msg113154) [3] (https://bitbucket.org/hudson/magic-lantern/pull-requests/745/dm-spy-extra-mpu_send-recv-stubs-for-500d/diff) (you can use this build (http://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/))
* Early discussion regarding button interrupt: http://www.magiclantern.fm/forum/index.php?topic=3189.0
* Button codes in QEMU: http://magiclantern.fm/forum/index.php?topic=2864.msg169517#msg169517
* First trick implemented using a MPU message:
Quote from: Greg on July 21, 2016, 03:22:31 PM
500D, LV
mpu_send(06 04 09 00 00)
mpu_recv(3c 3a 09 00 3c 3c e0 00 3f 80 00 00 38 12 c0 00 b9 cb c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 11 10 50 49 02 59 88 88 00 32 00 00 00 00 00 01 00 00 00)
PROP_LV_LENS
0x32 - focal length
0x10 - aperture
Now we can read lens_info in Photo mode.
Just call mpu_send(06 04 09 00 00). CPU receives data and automatically overwrite property lens_info.
(https://s32.postimg.cc/3kk7nrbqd/500d.jpg) (https://s32.postimg.cc/hfii6865h/500d2.jpg)
5D3: 0x08, 0x09, 0x01, num_steps_hi, num_steps_lo, 0x07, 0x00, 0x00: lens focus control in LiveView (also works in paused LiveView). Commands appear to be queued properly, but breaks focus distance reporting.
Related: http://magiclantern.wikia.com/wiki/Focus (struct prop_focus) and http://www.magiclantern.fm/forum/index.php?topic=4997 .
Quote from: a1ex on July 22, 2016, 10:46:21 PM
Something worth trying IMO:
/* stub for EOS M 2.0.2; "dwSize < TXBD_DATA_SIZE" */
void (*mpu_send)(char*,int) = (void*) (0xFFA872BC - 0xFFA69590);
char msg[] = { 0x08, 0x09, 0x01, 0x10, 0x00, 0x07, 0x00, 0x00 };
mpu_send(msg, msg[0]);
Ref: http://www.magiclantern.fm/forum/index.php?topic=17596.msg170023#msg170023
This code works on 5D3?
500D to display lens_info :
void (*mpu_send)(char*,int) = (void*) (0xFF18A884);
char msg[] = { 0x04, 0x09, 0x00 };
mpu_send(msg, 5);dm-log
mpu_send(06 04 09 00 19)
Yes, it does. Correction:
char msg[] = { 0x04, 0x09, 0x00, 0x00 };
mpu_send(msg, msg[0]);
The first number in a MPU message is transfer_size (always even), and the second number is message_size. Since MPU messages are transferred 16 bits at a time, transfer_size is (message_size + 2) & 0xFE (that is, either message_size + 1 or message_size + 2). When calling mpu_send, we need to pass only the useful part of the message (that is, message_size + message_content). The transfer size and the leading zero, if any, are added by mpu_send.
In other words, when you start a MPU message with 0x04, you must provide 4 values.
Side note: I'm pretty sure the same command (requesting LV lens info) can be done using properties, somehow.
Sensor cleaning :
mpu_send(06 05 04 0d 04 00) // ACTIVE_SWEEP_STATUS : 4 (sensor cleaning with shutter)
mpu_send(06 05 04 0d 01 00) // ACTIVE_SWEEP_STATUS : 1 (sensor cleaning without shutter)Quote from: a1ex on July 23, 2016, 06:31:18 AM
Side note: I'm pretty sure the same command (requesting LV lens info) can be done using properties, somehow.
**INTERRUP TryPostEvent(&"TaskClass", &"LiveViewMgr", 0x2, 0x0, 0x0), from ff0da5bc
LiveViewMg before3_mpu_send(&"StateObject", &"LiveViewMgr", 0x2, 0x0, 0x0), from ff1a6298
LiveViewMg prop_request_change(0x80050000, 0x15a124, 0x4), from ff035270
prop data = 2
LiveViewMg TryPostEvent(&"TaskClass", &"PropMgr", 0x6, 0xa63744, 0xc), from ff059cfc
LiveViewMg TryPostEvent(&"TaskClass", &"LVC_AE", 0x3, 0x4086b9d4, 0x0), from ff03528c
LiveViewMg TryPostEvent(&"TaskClass", &"LVC_DEV", 0x1, 0x40a637d4, 0x0), from ff0363e4
PropMgr before3_mpu_send(&"StateObject", &"PropMgr", 0x6, 0xa63744, 0xc), from ff1a6298
PropMgr before2_mpu_send(0xff42d278), from ff1876c8
PropMgr before1_mpu_send(0x9, 0x0, 0x1), from ff188bd0
PropMgr mpu_send(06 04 09 00 00), from ff05c438
Electronic level :
ml_init:00070fe8:00:00: *** RollingPitching(0x0), from 4d6b4
ml_init:ff1be48c:83:03: GUI_SetRollingPitchingLevelStatus Status(0)
ml_init:00070fe8:00:00: *** prop_request_change(0x80030039, 0x14fa8, 0x6), from 4d6b4
ml_init:00093d18:00:00: prop data = 0
ml_init:00070fe8:00:00: *** TryPostEvent(&"TaskClass", &"PropMgr", 0x6, 0xa42d94, 0xe), from ff059cfc
PropMgr:00070fe8:00:00: *** before3_mpu_send(&"StateObject", &"PropMgr", 0x6, 0xa42d94, 0xe), from ff1a6298
PropMgr:00070fe8:00:00: *** afterRollingPitching(0xff42ce18, 0xa42d9c, 0xff188c1c, 0x3), from ff1876c8
PropMgr:00070fe8:00:00: *** before1_mpu_send(0x3, 0x3a, 0x7), from ff188c50
PropMgr:000710e0:00:00: *** mpu_send(0c 0a 03 3a 00 00 00 00 00 00 00), from ff05c438
GUI_SetRollingPitchingLevelStatus Status(0)
mpu_send(0c 0a 03 3a 00 00 00 00 00 00 00)
GUI_SetRollingPitchingLevelStatus Status(1)
mpu_send(0c 0a 03 3a 01 00 00 00 00 00 00)
It looks like the CPU sends a request to the MPU, but no response.
Image orientation :
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 00 ...) // horizontal
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 00 ...) // horizontal
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 02 ...) // rotate 270 CW
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 02 ...) // rotate 270 CW
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 01 ...) // rotate 90 CW
mpu_recv(3e 3c 05 03 01 01 00 00 00 00 03 00 01 ...) // rotate 90 CW
Possible that this is related to the electronic level, yet I'm not sure.
So many exciting things happening with this project lately, this being just one of them.
In the spirit of DeafEyeJedi.......Keep up the good work. :)
Video temperature :
mpu_recv(06 05 03 38 af 00) // 0xAF - 128 = 47°C
PROP_BOARD_TEMP 47Ž
Photo temperature :
mpu_recv(06 05 03 17 9e 00) // 0x9E - 128 = 30°C
Temp_RAW_to_C(0x9e)
PROP_EFIC_TEMP 30Ž
Temp_RAW_to_C -> http://www.magiclantern.fm/forum/index.php?topic=9673.msg170387#msg170387
On TX19 side of 550D , sub_0x15620 sends msg to main MPU with HSIO0 ,
here are some examples sent out to main MPU :
char msg[] = { 0x05, 0x07, 0x01, 0x00 , 0x0};
char msg[] = { 0x05, 0x07, 0x01, 0x01 , 0x0};
char msg[] = { 0x05, 0x07, 0x01, 0x02 , 0x0};
char msg[] = { 0x05, 0x07, 0x00, 0x03 , 0x0};
char msg[] = { 0x05, 0x07, 0x00, 0x04 , 0x0};
On EOS-550D ,TX19a may send the following msg to main CPU :
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
@alex , in your posting ,
mpu_recv(3c 3a 09 00 3c 3c e0 00 3f 80 00 00 38 12 c0 00 b9 cb c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 11 10 50 49 02 59 88 88 00 32 00 00 00 00 00 01 00 00 00)
PROP_LV_LENS
My wild guessing , all of 11 10 50 are Aperture , pobably current aperture , max aperture , mini aperture respectively .
EDIT : almost 100% sure about definition of 11 10 50 mentioned above.
Great findings, leegong. Your hints are very helpful for emulating the MPU firmware in QEMU - something that was a pipe dream until recently.
char msg[] = { 0x05, 0x03, 0x04, power_kind , 0 }; // power_kind = 0 : LI , 1 : AM , 2 : AC
char msg[] = { 0x05, 0x03, 0x05, power_level , 0 }; // when power_kind == 2 ( AC ) , power_level = 2
Is this large chip at the upper left corner of 760D MPU?
(http://thumbnails116.imagebam.com/50196/6783c6501952610.jpg) (http://www.imagebam.com/image/6783c6501952610)
char msg[] = { 0x06, 0x09, 0x13, , end , AF_driving_speed , unknwon_para }; // focus to infinite or nearest end , no idea about what's the meaning of the last byte , probably related to timeout .
this is leegong 8) from nikonhackers, right? welcome!
Thank you nikfreak . i'm nikonhacker leegong , i'm newbie here , i'm glad to learn Canon hacking from you guys here ,
TX19A43 in EOS 550D is almost same as TX19A44 in Nikon D5100 , i'm happy and willing to add value to Magic Lantern project .
TX19a is responsible for communicating with AF sensor / AE sensor ,
but i have no idea about which part of TX19 is connected to AF sensor / AE sensor ,
any hardware connection info for TX19a on EOS 550D side ?
leegong
I have no idea either, but I can find out some MPU messages related to AF and AE, if it helps.
**INT-36h*:00ca8dac:00:00: *** mpu_recv(18 17 0a 08 0f 00 02 00 01 01 a0 10 00 68 01 01 50 20 25 01 01 00 48 00), from ff1bf420
MainCtrl:ff01e44c:9c:01: ID:8(21)
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[1][4][2]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd140:9f:01: tv 68
MainCtrl:ff0bd15c:9f:01: range tv a0,10
MainCtrl:ff0bd1bc:9f:01: av 25
MainCtrl:ff0bd1d8:9f:01: range av 50,20
MainCtrl:ff0bd214:9f:01: iso 48
MainCtrl:ff01bf50:89:03: bindReceiveNewTFTOLC
MainCtrl:ff024524:85:03: GUI_Control:90 0xbeb5b8
MainCtrl:ff01e44c:9c:01: ID:8000002C(22)
PropMgr:ff039df0:33:01: ptpPropChangeEvCBR[8000002c][4][68]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][9]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][49]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][49]
PropMgr:ff039df0:33:01: ptpPropChangeEvCBR[8000002d][4][25]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][9]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][49]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][49]
PropMgr:ff039df0:33:01: ptpPropChangeEvCBR[8000002e][4][48]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][9]
**INT-36h*:00ca8dac:00:00: *** mpu_recv(0e 0c 0a 08 09 00 03 00 01 01 00 6b 00), from ff1bf420
MainCtrl:ff01e44c:9c:01: ID:8(6)
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[1][4][3]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd214:9f:01: iso 6b
**INT-36h*:00ca8dac:00:00: *** mpu_recv(14 13 0a 08 49 00 02 00 01 01 00 70 01 01 f8 00 00 00 00 00), from ff1bf420
MainCtrl:ff01e44c:9c:01: ID:8(27)
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[1][4][2]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd214:9f:01: iso 70
MainCtrl:ff0bd078:9f:01: aeb_count 0
**INT-36h*:00ca8dac:00:00: *** mpu_recv(20 1e 0a 08 49 09 02 00 01 01 00 5b 01 01 00 00 00 00 00 00 00 00 00 01 40 01 00 00 00 00 00), from ff1bf420
MainCtrl:ff01e44c:9c:01: ID:8(22)
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[1][4][2]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd214:9f:01: iso 5b
MainCtrl:ff0bd078:9f:01: aeb_count 0
MainCtrl:ff0bd340:9f:01: rmt_olc_com_gr8:0,0,0
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[3][4][0]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd36c:9f:01: focusstatus 1,1
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[0][4][4001]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd49c:9f:01: focusinfo 1,40,1
MainCtrl:ff01bf50:89:03: bindReceiveNewTFTOLC
MainCtrl:ff024524:85:03: GUI_Control:90 0xbf2f44
PropMgr:ff039df0:33:01: ptpPropChangeEvCBR[8000002e][4][5b]
PropMgr:ff0399c4:33:01: SendPipeEvent [0][0][9]
PropMgr:00c7b3b4:00:00: PROP_ISO_AUTO 91
**INT-36h*:00ca8dac:00:00: *** mpu_recv(12 11 0a 08 00 09 00 00 00 00 00 00 00 00 00 00 00 00), from ff1bf420
MainCtrl:ff01e44c:9c:01: ID:8(24)
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[0][4][0]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd340:9f:01: rmt_olc_com_gr8:0,0,0
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[3][4][0]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd36c:9f:01: focusstatus 0,1
MainCtrl:ff03a3a4:33:01: PD_NotifyOlcInfoChanged[0][4][0]
MainCtrl:ff0399c4:33:01: SendPipeEvent [0][0][10]
MainCtrl:ff0bd49c:9f:01: focusinfo 0,0,1
So, 0a 08 is a complex message with variable size that appears to send exposure info and focus status from MPU to the main CPU.
Focus status messages are only sent in LiveView (contrast-detect AF):
#define PROP_LV_FOCUS_STATE 0x80050009 // 1 OK, 101 bad, 201 not done?
PropMgr:00ca8d64:00:00: *** mpu_send(06 05 09 0b 02 00), from ff05e224
PropMgr:ff02a148:8f:02: dcsChangeAckCBR (0x80050009, 0x201)
Gmt:ff100128:98:03: PROP_LV_AF_RESULT 1 2
PropMgr:00ca8d64:00:00: *** mpu_send(06 05 09 0b 00 00), from ff05e224
PropMgr:ff02a148:8f:02: dcsChangeAckCBR (0x80050009, 0x1)
Gmt:ff100128:98:03: PROP_LV_AF_RESULT 1 0
// not sure about this one
PropMgr:00ca8d64:00:00: *** mpu_send(26 24 09 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00), from ff05e224
PropMgr:ff02a148:8f:02: dcsChangeAckCBR (0x80050009, 0x200)
Gmt:ff0fe5c4:98:02: [GMT] gmtProperty ID=0x80050009(0x200)
Gmt:ff100128:98:03: PROP_LV_AF_RESULT 0 2
Gmt:ff261044:98:03: TA10 OFF (AF Start)
I could not find any property triggered when focusing outside LiveView, except for NotifyOlcInfoChanged. The focus confirmation status (e.g. for dot_tune AFMA) is recognized by ML from the "focusinfo" messages triggered by that property, and it's also sent in manual focus mode, so this one must be related to AF sensor somehow.
Hope it helps.
Welcome aboard @leegong -- I just did my first Nikon hack on a co-worker's D5100 and was surprised at how eerily similar the installation process was. Very NHDK tho. [emoji2]
Glad to have you on this project!
Thanks , DeafEyeJedi , nice to meet you and work with you on this project .
I'll be very glad to discuss Nikon D5100 hacking with you on Nikonhacker forum if you like .
I'm searching for msg class 0xA on TX19 size , no result yet .
Upon receiving msg 0x1 , 0x4 , TX19 seems to change AF mode , AF point .
EDIT : msg 01 05 seems to change TV .
char msg {0x? , 0xA , 0x8 , flag00 , flag01 , data00 , data01 .......} ;
each bit of flag00 , flag01 indicates a specific type of data paylaod is present in msg0A08 or not ,
so there are 16 kinds of different data structure , only 13 kinds of payload type are available in 550D TX19 .
00000000 struc_4 struc # (sizeof=0x4) # XREF: ROM:TAB_Msg0A08_payload_formatr
00000000 Msg0A_08_PayloadType_offset:.byte ?
00000001 Msg0A_08_payload_type:.byte ?
00000002 Msg0A_08_payload_offset:.byte ?
00000003 Msg0A_08_payload_size:.byte ?
00000004 struc_4 ends
ROM:0001884E TAB_Msg0A08_payload_format:struc_4 < 3, 1, 5, 2> # 0
ROM:0001884E # DATA XREF: ROM:off_21504o
ROM:0001884E # Report_MSG0A_08+7Ar ...
ROM:0001884E struc_4 < 3, 2, 7, 6> # 1
ROM:0001884E struc_4 < 3, 4, 0xD, 5> # 2
ROM:0001884E struc_4 < 3, 8, 0x12, 4> # 3
ROM:0001884E struc_4 < 3, 0x10, 0x16, 4> # 4
ROM:0001884E struc_4 < 3, 0x20, 0x1A, 6> # 5
ROM:0001884E struc_4 < 3, 0x40, 0x20, 7> # 6
ROM:0001884E struc_4 < 3, 0x80, 0x27, 3> # 7
ROM:0001884E struc_4 < 4, 1, 0x2A, 5> # 8
ROM:0001884E struc_4 < 4, 2, 0x2F, 5> # 9
ROM:0001884E struc_4 < 4, 4, 0x34, 5> # 0xA
ROM:0001884E struc_4 < 4, 8, 0x39, 6> # 0xB
ROM:0001884E struc_4 < 4, 0x10, 0x3F, 1> # 0xC
Quote from: a1ex on July 22, 2016, 10:43:28 PM
5D3: 0x08, 0x09, 0x01, num_steps_hi, num_steps_lo, 0x07, 0x00, 0x00: lens focus control in LiveView (also works in paused LiveView).
07 in the msg above is Focus driving speed .
Quote from: Greg on July 21, 2016, 03:22:31 PM
500D, LV
mpu_send(06 04 09 00 00)
mpu_recv(3c 3a 09 00 3c 3c e0 00 3f 80 00 00 38 12 c0 00 b9 cb c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 11 10 50 49 02 59 88 88 00 32 00 00 00 00 00 01 00 00 00)
PROP_LV_LENS
0x32 - focal length
0x10 - aperture
Since msg 09 00 is PROP_LV_LENS , meanwhile msg 09 12 is exactly same as msg 09 00 , i guess msg 09 12 is for photo mode .
Payload of msg 09 14 includes short integer LensFocusPosition and long integer timing
Lens max aperture ， minimum aperture ， Lens ID ， Wide FocalLength ， tele Focal Length ...... are inside msg 03 15
Any description or info of any Msg is appreciated , for example msg 05 02 , msg 09 17 , msg 08 02......
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.
it would be cool if you could merge your findings. e.g. in the magic lantern wiki on wikia? http://magiclantern.wikia.com/wiki/
Quote from: g3gg0 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/
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 .
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 ?
I have a couple of messages described on the QEMU branch: extract_init_spells.py (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/extract_init_spells.py). This script parses a startup-log (https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/) and outputs a header file with the MPU conversation, with comments where the spells are known. Example: 60D.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/60D.h), 50D.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/50D.h).
My startup logs used to create the above headers are here (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/qemu/startup-logs.7z) (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 (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/extract_button_codes.py) and button_codes.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/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 (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/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 (http://www.magiclantern.fm/forum/index.php?topic=2864.msg169517#msg169517)
- Parameterized MPU spells (http://www.magiclantern.fm/forum/index.php?topic=2864.msg185653#msg185653)
Example - entering Canon menu (5D3 1.2.3; 5D3-halfshutter.log (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/5D3-halfshutter.log)):
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 (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/5D3-halfshutter.log)):
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 (http://www.magiclantern.fm/forum/index.php?topic=17596.msg171988#msg171988) (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 (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/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 (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/5D3-mirror-up.log)
5D3-123-startup-lv1.log (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/5D3-123-startup-lv1.log)
700D-startup.log (http://a1ex.magiclantern.fm/bleeding-edge/startup-logs/700D-startup.log)
Unique entries:
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
The links to the log files are broken.
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 (https://bitbucket.org/hudson/magic-lantern/commits/896a1f5a7a5574caa4025306dcaa9807b8757c7e?at=qemu)), then run it under QEMU+GDB (example (http://www.magiclantern.fm/forum/index.php?topic=15895.msg187795#msg187795)).
- 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 (http://www.magiclantern.fm/forum/index.php?topic=19933) (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.
@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
They seem to match (QEMU button_codes.h):
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,
};
Here's how the full shutter event looks like:
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.
@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 ?
Yes, SW1 and SW2 are not like regular button events. Currently I emulate SW1 (half-shutter) like this:
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.
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.
Quote from: leegong on August 28, 2016, 03:37:06 PM
On EOS-550D ,TX19a may send the following msg to main CPU :
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).
Quote from: leegong on September 08, 2017, 05:12:01 PM
do you know , in which kind of MPU Msg , LensID mentioned above is sent to CPU ?
Just found out:
"03 15" : ("PROP_LENS",),
"03 24" : ("PROP_LENS_NAME",),
example:
{ 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 (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/extract_init_spells.py) (also exported to known_spells.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/known_spells.h))
@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.
@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"
Found out where MPU properties are handled - they are forwarded to PropMgr (which makes the analysis a bit difficult, as they are not handled in sync with mpu_recv messages). However, you can place two logging hooks (https://bitbucket.org/hudson/magic-lantern/commits/af43d85a9e6841ab7b2fb8d039d9a6191cafc48c) directly in PropMgr state object code:
- mpu_analyze_recv_data_log: string "NO AnalyzeMpuReceiveData"
- prop_lookup_maybe_log: string "NOT PROPERTYLIST ID"
These two will match the MPU message to its corresponding property. Example for 550D (enable MPU messages and properties in 550D/debugmsg.gdb):
./run_canon_fw.sh 550D,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x 550D/debugmsg.gdb
...
[MPU] Sending : 08 06 01 23 00 01 00 00
[ INT-36h:ff1bb1e0 ] mpu_recv( 08 06 01 23 00 01 00 )
... after a while, likely after processing other messages ...
[ PropMgr:ff056cb0 ] PropState: (0) --10--> (0) ff1b712c (x=726cf0 z=72a954 t=14)
[ PropMgr:ff1d85ac ] MPU property: 01 23 00 01 00
[ PropMgr:ff1b66ec ] prop_lookup_maybe 80000020 80000020 724f7c 2
That means MPU message 01 23 is mapped to property 0x80000020. Let's look it up (http://www.magiclantern.fm/forum/index.php?topic=4729.msg195282#msg195282):
./run_canon_fw.sh 550D,firmware="boot=0" -d debugmsg |& grep --text -C 5 80000020
...
[ CtrlSrv:ff1fba44 ] (84:02) copyDataToStorage eventID(0x80000020)Data(1)size(0)
[ CtrlSrv:ff1fcf30 ] (83:03) PROP_CARD1_STATUS[1]
...
The above will only cover properties coming from the MPU (e.g. during startup). Luckily, these can be brute-forced (https://bitbucket.org/hudson/magic-lantern/commits/1699165b91887ad21a1216cf7ac947bad3eb3e02#chg-contrib/qemu/eos/mpu_spells/bruteforce.h): send all possible messages in the same class and see how the firmware reacts - in most cases it won't crash, but it won't boot the GUI either. It will reveal the matching property ID for most messages.
For properties sent from the main CPU to the MPU (e.g. if a setting is changed from Canon menus or from ML), enable the logging hook for prop_request_change (also in debugmsg.gdb) and explore the menus, writing down the properties triggered in the process.
Documented a bunch of properties with these methods, in the usual place: extract_init_spells.py (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/extract_init_spells.py) and exported to known_spells.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/known_spells.h).
Cross-checking welcome - it's impossible not to find a few missing or misspelled ones.
Quote from: leegong on September 14, 2016, 11:50:01 AM
char msg {0x? , 0xA , 0x8 , flag00 , flag01 , data00 , data01 .......} ;
each bit of flag00 , flag01 indicates a specific type of data paylaod is present in msg0A08 or not ,
500D 111: this happens at FF0A5A20.
Quote
so there are 16 kinds of different data structure , only 13 kinds of payload type are available in 550D TX19.
These are at FF41C140; payload sizes and handlers are:
id size handler
0 2 unknown
1 6 tv, tv_range
2 5 av, av_range
3 4 iso
4 4 empty (this field is the picture count at the bottom of the screen; likely handled elsewhere
5 6 unknown
6 7 aeb_count (last byte)
7 3 empty
8 5 focusstatus
9 5 empty
a 5 empty
b 6 focusinfo
c 1 empty
d 0 empty
e 0 empty
f 0 empty
Sizes match the ones from leegong.
Please find a script that annotates MPU logs (containing mpu_send and mpu_recv calls). So far, it prints the property name and the GUI event ID, if known.
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/annotate_mpu_log.py
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/known_spells.py
The script must be run from the mpu_spells directory, as it imports known_spells.py and also looks in button_codes.h to pick the (model-specific) button codes and names. Or, copy it alongside with these two files if you decide to move it.
Sample output:
45.915.489 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 06 26 01 00) ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
45.915.734 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 06 20 01 00) ; BGMT_Q
45.923.365 PropMgr:ff122df8:00:00: *** mpu_send(0a 08 09 1a 00 00 00 00 00) ; PROP 8005002A
45.924.215 PropMgr:ff122df8:00:00: *** mpu_send(06 05 04 00 00 00) ; NotifyGUIEvent
45.924.645 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 06 0a 00 00) ; BGMT_UNPRESS_ZOOM_OUT
45.924.844 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 06 09 00 00) ; BGMT_UNPRESS_ZOOM_IN
45.925.009 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 04 00 00 01) ; NotifyGUIEvent
45.925.637 **INT-36h*:ff2e4494:00:00: *** mpu_recv(08 06 01 0b 00 00 00) ; PROP_AEB
45.928.221 PropMgr:ff122df8:00:00: *** mpu_send(08 06 00 00 04 00 00) ; Complete WaitID = NotifyGUIEvent
45.931.410 PropMgr:ff122df8:00:00: *** mpu_send(06 05 03 34 00 00) ; PROP_Q_POSITION
@a1ex:
Upon receiving Msg08 02 , MPU gets function code in payload of Msg , which is 0 - 0x7F in 550D ,
each function code stands for one kind of specific action or operation on MPS side :
function code 0xF : send lens custom CMD
function code 0x10 : maybe drive lens focus motor
function code 0x48 : read current Lens data
function code 0x60 : calculate checksum of FW on MPU side
function code 0x68 : fresh current unknown temperature
function code 0x6B : get current PROP_EFIC_TEMP and stores it into eeprom.
That sounds useful; I should probably resume the MPU emulation experiments (if only to learn how to read MIPS code).
Any idea where this might be used in Canon code? Tried to grep for this command in my logs with MPU messages, but found nothing.
Quote from: a1ex on March 28, 2018, 11:10:29 AM
Any idea where this might be used in Canon code? Tried to grep for this command in my logs with MPU messages, but found nothing.
My wild guessing , these Msg08 02 might belong to factory debug section ,
they don't belong to normal Msg transfering workflow between MPU and CPU .
00023BD0 Msg08_02_CallTable:.word Action_On_Msg0802_fun00+1 # 0
ROM:00023BD0 # DATA XREF: Msg08_Handler+134r
ROM:00023BD0 .word Action_On_Msg0802_fun01+1 # 1 # in a0 = 0xFFFFD2E0
ROM:00023BD0 .word Action_On_Msg0802_fun02+1 # 2
ROM:00023BD0 .word Action_On_Msg0802_fun03_load_EEPROM_2_RAM+1 # 3
ROM:00023BD0 .word Action_On_Msg0802_fun04_get_Image_orientation+1 # 4
ROM:00023BD0 .word Action_On_Msg0802_fun05+1 # 5
ROM:00023BD0 .word Action_On_Msg0802_fun06+1 # 6
ROM:00023BD0 .word Action_On_Msg0802_fun07+1 # 7
ROM:00023BD0 .word Action_On_Msg0802_fun08+1 # 8
ROM:00023BD0 .word Action_On_Msg0802_fun09+1 # 9
ROM:00023BD0 .word Action_On_Msg0802_fun0A+1 # 0xA
ROM:00023BD0 .word Action_On_Msg0802_fun0B+1 # 0xB
ROM:00023BD0 .word Action_On_Msg0802_fun0C+1 # 0xC
ROM:00023BD0 .word Action_On_Msg0802_fun0D+1 # 0xD
ROM:00023BD0 .word Action_On_Msg0802_fun0E+1 # 0xE
ROM:00023BD0 .word Action_On_Msg0802_fun0F_custom_LensCMD+1 # 0xF
ROM:00023BD0 .word Action_On_Msg0802_fun10_FocusScan+1 # 0x10
ROM:00023BD0 .word Action_On_Msg0802_fun11+1 # 0x11
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x12
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x13
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x14
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x15
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x16
ROM:00023BD0 .word Action_On_Msg0802_fun13+1 # 0x17
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x18
ROM:00023BD0 .word Action_On_Msg0802_fun19_Lens_RTX_1byte+1 # 0x19
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1A
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1B
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1C
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1D
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1E
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x1F
ROM:00023BD0 .word Action_On_Msg0802_fun20+1 # 0x20
ROM:00023BD0 .word Action_On_Msg0802_fun21+1 # 0x21
ROM:00023BD0 .word Action_On_Msg0802_fun22+1 # 0x22
ROM:00023BD0 .word Action_On_Msg0802_fun23+1 # 0x23
ROM:00023BD0 .word Action_On_Msg0802_fun24+1 # 0x24
ROM:00023BD0 .word Action_On_Msg0802_fun25+1 # 0x25
ROM:00023BD0 .word Action_On_Msg0802_fun26+1 # 0x26
ROM:00023BD0 .word Action_On_Msg0802_fun27+1 # 0x27
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x28
ROM:00023BD0 .word Action_On_Msg0802_fun29+1 # 0x29
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x2A
ROM:00023BD0 .word Action_On_Msg0802_fun2B+1 # 0x2B
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x2C
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x2D
ROM:00023BD0 .word Action_On_Msg0802_fun2E+1 # 0x2E
ROM:00023BD0 .word Action_On_Msg0802_fun2F+1 # 0x2F
ROM:00023BD0 .word Action_On_Msg0802_fun30_DISPALLOFF+1 # 0x30
ROM:00023BD0 .word Action_On_Msg0802_fun31_DISPALLON+1 # 0x31
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x32
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x33
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x34
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x35
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x36
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x37
ROM:00023BD0 .word Action_On_Msg0802_fun38+1 # 0x38
ROM:00023BD0 .word Action_On_Msg0802_fun39+1 # 0x39
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x3A
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x3B
ROM:00023BD0 .word Action_On_Msg0802_fun3C+1 # 0x3C
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x3D
ROM:00023BD0 .word Action_On_Msg0802_fun3E+1 # 0x3E
ROM:00023BD0 .word Action_On_Msg0802_fun3F+1 # 0x3F
ROM:00023BD0 .word Action_On_Msg0802_fun40+1 # 0x40
ROM:00023BD0 .word Action_On_Msg0802_fun41+1 # 0x41
ROM:00023BD0 .word Action_On_Msg0802_fun42+1 # 0x42
ROM:00023BD0 .word Action_On_Msg0802_fun43+1 # 0x43
ROM:00023BD0 .word Action_On_Msg0802_fun44+1 # 0x44
ROM:00023BD0 .word Action_On_Msg0802_fun45+1 # 0x45
ROM:00023BD0 .word Action_On_Msg0802_fun46+1 # 0x46
ROM:00023BD0 .word Action_On_Msg0802_fun47+1 # 0x47
ROM:00023BD0 .word Action_On_Msg0802_fun48_copy_Lens_aperture_data+1 # 0x48
ROM:00023BD0 .word Action_On_Msg0802_fun49_read_EEPROM+1 # 0x49
ROM:00023BD0 .word Action_On_Msg0802_fun4A+1 # 0x4A
ROM:00023BD0 .word Action_On_Msg0802_fun4B+1 # 0x4B
ROM:00023BD0 .word Action_On_Msg0802_fun4C+1 # 0x4C
ROM:00023BD0 .word Action_On_Msg0802_fun4D+1 # 0x4D
ROM:00023BD0 .word Action_On_Msg0802_fun4E_read_button+1 # 0x4E
ROM:00023BD0 .word Action_On_Msg0802_fun4F_backup_byte20004+1 # 0x4F
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x50
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x51
ROM:00023BD0 .word Action_On_Msg0802_fun52+1 # 0x52
ROM:00023BD0 .word Action_On_Msg0802_fun53+1 # 0x53
ROM:00023BD0 .word Action_On_Msg0802_fun54+1 # 0x54
ROM:00023BD0 .word Action_On_Msg0802_fun55+1 # 0x55
ROM:00023BD0 .word Action_On_Msg0802_fun56+1 # 0x56
ROM:00023BD0 .word Action_On_Msg0802_fun57+1 # 0x57
ROM:00023BD0 .word Action_On_Msg0802_fun58+1 # 0x58
ROM:00023BD0 .word Action_On_Msg0802_fun59+1 # 0x59
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5A
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5B
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5C
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5D
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5E
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x5F
ROM:00023BD0 .word Action_On_Msg0802_fun60_cal_MPU_CodeArea_checksum+1 # 0x60
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x61
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x62
ROM:00023BD0 .word Action_On_Msg0802_fun63+1 # 0x63
ROM:00023BD0 .word Action_On_Msg0802_fun64+1 # 0x64
ROM:00023BD0 .word Action_On_Msg0802_fun65+1 # 0x65
ROM:00023BD0 .word Action_On_Msg0802_fun66+1 # 0x66
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x67
ROM:00023BD0 .word Action_On_Msg0802_fun68_Fresh_temperature+1 # 0x68
ROM:00023BD0 .word Action_On_Msg0802_fun69_read_EEPROM_0x113B+1 # 0x69
ROM:00023BD0 .word Action_On_Msg0802_fun6A_write_EEPROM_0x113B+1 # 0x6A
ROM:00023BD0 .word Action_On_Msg0802_fun6B_read_temperature+1 # 0x6B
ROM:00023BD0 .word Action_On_Msg0802_fun6C+1 # 0x6C
ROM:00023BD0 .word Action_On_Msg0802_fun6D+1 # 0x6D
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x6E
ROM:00023BD0 .word Action_On_Msg0802_fun6F+1 # 0x6F
ROM:00023BD0 .word Action_On_Msg0802_fun70+1 # 0x70
ROM:00023BD0 .word Action_On_Msg0802_fun71+1 # 0x71
ROM:00023BD0 .word Action_On_Msg0802_fun72+1 # 0x72
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x73
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x74
ROM:00023BD0 .word Action_On_Msg0802_fun75_read_RAM_byte+1 # 0x75
ROM:00023BD0 .word Action_On_Msg0802_fun76+1 # 0x76
ROM:00023BD0 .word Action_On_Msg0802_fun77_NULL+1 # 0x77
ROM:00023BD0 .word Action_On_Msg0802_fun78+1 # 0x78
ROM:00023BD0 .word Action_On_Msg0802_fun79_change_button_flag+1 # 0x79
ROM:00023BD0 .word Action_On_Msg0802_fun7A_EEPROM_0x1360_verify+1 # 0x7A
ROM:00023BD0 .word Action_On_Msg0802_fun7B+1 # 0x7B
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x7C
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x7D
ROM:00023BD0 .word Action_On_Msg0802_clear_RAM_byte+1 # 0x7E
ROM:00023BD0 .word Action_On_Msg0802_fun7F+1 # 0x7F
Do you happen to know any low-level details on the MPU communication? (e.g. what I/O registers are used for that, or where the messages are sent/received in Canon code). For the ARM side, I've documented the process in the MPU communication (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-mpu-communication) section in the QEMU RE guide.
The RXDMPU/TXDMPU (https://www.magiclantern.fm/forum/index.php?topic=7531) pins from the battery grip connector are also a good choice for investigation (requires an Arduino board or equivalent).
@a1ex :
SC1 on MPU side is responsible for these debug info communication .
I guess that maybe there is a backdoor in normal communication workflow for normal Msg , but not found yet .
In Nikon d5100 , both of UART(similar as SC1 in 550D) and HSC (similar as HSC for communication between
MPU and CPU in 550D) may communicate debug CMD .
@a1ex，here is debug UI on 550D MPU side :
ROM:00004448 asc_4448: .ascii "-----------------------------------------------------------\n"
ROM:00004448 # DATA XREF: TITLE+12o
ROM:00004448 # TITLE+20o
ROM:00004448 .ascii " K270 Debug Monitor (Ver 1.00) \n"
ROM:00004448 .ascii " Copyright(C) CANON INC. 2007 All Rights Reserved. \n"
ROM:00004448 .ascii "-----------------------------------------------------------\n"
ROM:00004448 .ascii 0
ROM:00004539 .byte 0xFF
ROM:0000453A .byte 0xFF
ROM:0000453B .byte 0xFF
@a1ex:
After Msg05 03 (after release data) is sent from MPU to CPU ,
MPU may send AF debug info to CPU , size of AF debug info is inside Msg05 08 ,
payload of AFdebug info is probably sent to CPU with Multi-Msg05 09 .
How AFdebug info is used on CPU side ? is it for Canon private AF info in CR2 ?
Here's a conversation during a still photo capture (1/60 ISO 800 triggered from LiveView, 5D3 1.1.3):
0.324.096 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 04 05 01 00) ; EVENTID_RELEASE_ON
0.324.443 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 04 05 0e 00) ; EVENTID_RELEASE_START
0.324.735 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 04 17 00 00) ; PROP_REMOTE_SW2
0.325.044 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 03 12 00 00) ; ???
0.326.144 ShootCaptu:ff14b8ac:93:03: scsReleaseOn
0.326.459 ShootCaptu:ff147854:93:03: scsReleaseStart
0.326.840 **INT-36h*:ff2e4494:00:00: *** mpu_recv(38 36 05 02 53 00 53 00 60 00 00 bd 00 ae 00 03 00 00 00 00 00 00 03 00 0 06 00 00 00 a3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 01 01 00) ; EVENTID_RELEASE_DATA_SW2ON
0.331.468 **INT-36h*:ff2e4494:00:00: *** mpu_recv(10 0f 0a 08 41 00 04 00 01 01 fb 01 01 fb 00 00) ; PD_NotifyOlcInfoChanged
0.352.199 ShootCaptu:ff14827c:93:03: scsReleaseData
0.360.349 ShootCaptu:ff1489ac:93:03: EShutCapture(scsReleaseData)
0.367.974 ShootCaptu:ff1491a0:93:03: scsDummyCapEnd
0.372.660 PropMgr:ff122df8:00:00: *** mpu_send(0a 08 03 0b 00 00 00 01 00) ; PROP 80030007
0.375.111 ShootCaptu:ff14b6f4:93:03: scsProperty ID=0x80030012(0x16)
0.382.693 PropMgr:ff122df8:00:00: *** mpu_send(08 07 01 2a 23 59 00 40) ; PROP_CARD2_FILE_NUMBER
0.385.863 ShootCaptu:ff1492a8:93:03: scsDummyReadoutDone
0.386.295 ShootCaptu:ff149378:93:03: EShutCapture(scsDummyReadoutDone)
0.392.720 PropMgr:ff122df8:00:00: *** mpu_send(06 05 03 07 07 00) ; PROP_BURST_COUNT
0.402.752 PropMgr:ff122df8:00:00: *** mpu_send(0a 08 03 06 00 00 00 cc 00) ; PROP_AVAIL_SHOT
0.412.779 PropMgr:ff122df8:00:00: *** mpu_send(06 05 03 07 0a 00) ; PROP_BURST_COUNT
0.424.119 ShootCaptu:ff149874:93:03: scsCapReady
0.424.143 ShootCaptu:ff1498e4:93:03: scsCapReady EShutter
0.473.119 PropMgr:ff122df8:00:00: *** mpu_send(06 05 03 19 01 00) ; PROP_TFT_STATUS
0.490.601 PropMgr:ff122df8:00:00: *** mpu_send(06 05 03 34 00 00) ; PROP_Q_POSITION
0.535.218 ShootCaptu:ff149c50:93:03: scsCapEnd
0.555.495 **INT-36h*:ff2e4494:00:00: *** mpu_recv(46 45 05 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a4 00) ; EVENTID_AFPintData
0.555.925 **INT-36h*:ff2e4494:00:00: *** mpu_recv(0c 0b 05 13 06 00 7d 1b 01 ac 0f 00) ; EVENTID_ImageParamData
0.556.715 EventMgr:ff0da6cc:93:03: scsAFPINTParamCBR(JobID=86909)
0.557.358 **INT-36h*:ff2e4494:00:00: *** mpu_recv(3a 39 05 03 01 01 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 0c a7 44 b3 d6 ba 6d 6b b3 78 b6 80 36 00) ; EVENTID_AFTER_RELEASE_DATA
0.557.486 EventMgr:ff0da638:93:03: scsIMAGEParamCBR(JobID=86909)
0.557.612 EventMgr:ff0dabd8:93:03: scsAfterReleaseDataCBR(86909)
0.629.940 **INT-36h*:ff2e4494:00:00: *** mpu_recv(0c 0a 0a 08 10 00 04 02 00 cc 00) ; PD_NotifyOlcInfoChanged
0.639.966 PropMgr:ff122df8:00:00: *** mpu_send(08 06 04 17 00 00 00) ; PROP_REMOTE_SW2
0.640.635 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 04 17 00 00) ; PROP_REMOTE_SW2
0.650.662 PropMgr:ff122df8:00:00: *** mpu_send(08 06 04 16 00 00 00) ; PROP_REMOTE_SW1
0.651.297 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 05 04 16 00 00) ; PROP_REMOTE_SW1
0.654.087 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 04 05 0f 00) ; EVENTID_RELEASE_END
0.654.429 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 04 05 04 00) ; EVENTID_RELEASE_OFF_SW2OFF
0.654.969 ShootCaptu:ff14a70c:93:03: scsReleaseEnd
0.655.040 ShootCaptu:ff14b8ec:93:03: scsReleaseOff
0.660.721 **INT-36h*:ff2e4494:00:00: *** mpu_recv(06 04 05 0b 00) ; EVENTID_METERING_TIMER_START_SW1OFF
0.661.112 **INT-36h*:ff2e4494:00:00: *** mpu_recv(08 06 09 0c 00 00 00) ; PROP_LV_HALF_SHUTTER
0.665.787 ShootCaptu:ff149d60:93:03: scsFinalReadoutDone
0.670.388 ShootCaptu:ff14a154:93:03: scsFinalReadoutDone (2057)
The AfterReleaseData is required to create a CR2, but I'm not sure how exactly it's used.
Some full logs here (https://www.magiclantern.fm/forum/index.php?topic=2388.msg197313#msg197313) (not this exact one, but in the same format). The SCS state machine (ShootCapture task) is described here (https://www.magiclantern.fm/forum/index.php?topic=1915.0).
Please find a custom build for logging MPU messages on most EOS models (and a few Canon messages, to get some context):
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/
Expected to work in demanding scenarios (such as LiveView or photo capture), unlike the general-purpose startup log (which is quite a bit more verbose).
The resulting logs should be annotated (https://www.magiclantern.fm/forum/index.php?topic=17596.msg198329#msg198329) to understand what's up with them (unless you already know MPU message codes by heart).
@a1ex :
Sorry , just get why no Msg 05 08 in your log , Msg05 08 is not enabled in usual setting , it's a hidden option ,
In 550D , Msg05 08 depends on 16bits setting data at eeprom ADDR 0x1042 ,
you have to modify setting in eeprom @0x1042 to enable Msg05 08 at first .
EDIT :
Msg08 02 fun_0x52 changes eeprom @0x1042.
Msg08 02 fun_0x53 reads eeprom @0x1042.
EDIT :
The 16bits comes from EEPROM @0x1042 ， but i have no idea about big endian or little endian in EEPROM ,
bit1:bit0 = 0 - Msg0508 disabled
bit1:bit0 = 1 ，2 ，3 - type of info data
Decoding of part of Msg05 02 :
00000000 struc_Msg05_02 struc # (sizeof=0x2E)
00000000 MsgHeader: struc_msg_header ? # == 0x2E , 0x5 , 0x2
00000003 TV?: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+2Ew
00000004 AV?: .byte ?
00000005 TV??ISO??: .byte ? # XREF: build_msg05_02_ReleaseBeforeData:loc_54462w
00000006 field_6: .byte ?
00000007 ISO_sure: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+D4w
00000008 field_8: .byte ?
00000009 LV_BV_char0: .byte ?
0000000A LV_BV_char1: .byte ?
0000000B field_B: .byte ?
0000000C field_C: .byte ? # == 0x3
0000000D field_D: .byte ?
0000000E field_E: .byte ?
0000000F _PROP_WBB_GM: .byte ?
00000010 _PROP_WBB_BA: .byte ?
00000011 _PROP_WBS_GM: .byte ?
00000012 _PROP_WBS_BA: .byte ?
00000013 field_13: .byte ?
00000014 field_14: .byte ?
00000015 field_15: .byte ?
00000016 field_16: .byte ?
00000017 field_17: .byte ?
00000018 field_18: .byte ?
00000019 LV_HALF_SHUTTER_bit0:.byte ?
0000001A temperature: .byte ?
0000001B Lens_attrib: .byte ?
0000001C _important_char0:.byte ?
0000001D _important_char1:.byte ?
0000001E _important_char2:.byte ?
0000001F Focal_Length: .half ?
00000021 Focus_Point: .half ?
00000023 field_23: .byte ?
00000024 field_24: .byte ?
00000025 field_25: .byte ?
00000026 field_26: .byte ?
00000027 field_27: .byte ?
00000028 field_28: .byte ?
00000029 field_29: .byte ?
0000002A field_2A: .byte ?
0000002B field_2B: .byte ?
0000002C field_2C: .byte ?
0000002D field_2D: .byte ?
0000002E struc_Msg05_02 ends
There are two kinds of Msg05 03 Release after data , the difference between them is from field0x1A to field0x29 ,
this section (16 bytes) may contains power info or AF info , depending on setting in eeprom .
Here is Msg05 03 which contains power info :
00000000 struc_Msg05_03 struc # (sizeof=0x3D)
00000000 MsgHeader: struc_msg_header ? # == 0x3D , 0x5 , 0x3
00000003 field_3: .byte ?
00000004 field_4: .byte ?
00000005 CYC07_timing_counter:.word ?
00000009 PROP_AF_MODE: .byte ?
0000000A field_A: .byte ?
0000000B Image_orientation:.byte ?
0000000C field_C: .byte ?
0000000D field_D: .byte ?
0000000E field_E: .byte ?
0000000F field_F: .byte ?
00000010 field_10: .byte ?
00000011 field_11: .byte ?
00000012 field_12: .byte ?
00000013 field_13: .byte ?
00000014 field_14: .byte ?
00000015 field_15: .byte ?
00000016 field_16: .byte ?
00000017 field_17: .byte ?
00000018 field_18: .byte ?
00000019 field_19: .byte ?
0000001A Vfo1_div_4: .byte ?
0000001B Vfo2_div_4: .byte ?
0000001C vbat_noload: .byte ?
0000001D vbat_bcon: .byte ?
0000001E field_1E: .byte ?
0000001F field_1F: .byte ?
00000020 _Resister:.byte ?
00000021 _remaining_capacity:.byte ?
00000022 field_22: .byte ?
00000023 field_23: .byte ?
00000024 field_24: .byte ?
00000025 field_25: .byte ?
00000026 field_26: .byte ?
00000027 field_27: .byte ?
00000028 field_28: .byte ?
00000029 field_29: .byte ?
0000002A FocusDistance_first?:.half ?
0000002C FocusDistance_second?:.half ?
0000002E field_2E: .byte ?
0000002F field_2F: .byte ?
00000030 field_30: .byte ?
00000031 field_31: .byte ?
00000032 field_32: .byte ?
00000033 field_33: .byte ?
00000034 field_34: .byte ?
00000035 field_35: .byte ?
00000036 field_36: .byte ?
00000037 field_37: .byte ?
00000038 field_38: .byte ?
00000039 field_39: .byte ?
0000003A field_3A: .byte ?
0000003B field_3B: .byte ?
0000003C field_3C: .byte ?
0000003D struc_Msg05_03 ends
Quote from: a1ex on June 25, 2017, 04:42:24 PM
On some models (those with TX19A (https://photo-parts.com.ua/parts/?part=TMP19A43) MPU), you can read the EEPROM, with the mpu_dump module. The 70D is not one of them - it uses F74966A (https://photo-parts.com.ua/parts/?part=F74966A), just like 100D and 700D. The 5D3 and 6D use F74965A (https://photo-parts.com.ua/parts/?part=F74965A), while the 650D and EOSM use F74964A (https://photo-parts.com.ua/parts/?part=F74964A). These are probably Fujitsu FR (just a guess), and the protocol for talking to the main CPU is the same as with those models with TX19A (many messages are actually identical).
Vanilla mpu_dump already outputs some valid files on 5D3:
- MPU-ROM.BIN (size 1MB, trying to dump more results in duplicate copies of the same data)
- MPU-EEP.BIN (last used lens names are present here)
Ran cpu_rec (https://github.com/airbus-seclab/cpu_rec) against MPU-ROM.BIN, and the closest one appears to be SuperH.
Guess: R5F74965ANBG?
String: V1.00-SH2A-FPU
Software (https://elmicro.com/files/renesas/sh2a_software_manual.pdf) manual (https://www.renesas.com/en-us/doc/products/mpumcu/001/rej09b0051_sh2a.pdf), hardware manual (https://www.renesas.com/en-us/doc/products/mpumcu/doc/superh/r01uh0025ej_sh7261_hm.pdf)
Renesas search page: F74 (https://www.renesas.com/en-us/search/parametric-search.html?part_name=f74)
Wanted: datasheet of a similar device (with SH2A-FPU core).
Quote from: a1ex on April 15, 2018, 03:58:11 PM
- MPU-EEP.BIN (last used lens names are present here)
This EEPROM content most probably stores AF calibration data, correct? If it is already readable and writeable on ML level (!), understanding its content should be the key to AF-adjustment in all bodies. Here I have an idea: reading the content before and after altering AFMA settings in a AFMA-enabled body. Might be, that this setting is transferred to MPU, which then stores it in EEPROM?
STROBO communication interface is found , lots of STROBO commands such as 0xA1 , 0xA2 .......
AE CCD data is found , double int16 7x9 array , low 10bits are effective , then converted into 8bits 7x9 array.
00000000 Msg0502_ReleaseBeforeData struc # (sizeof=0x2E)
00000000 MsgHeader: struc_msg_header ? # XREF: build_msg05_02_ReleaseBeforeData+Ew
00000000 # build_msg05_02_ReleaseBeforeData+12w ... # == 0x2E , 0x5 , 0x2
00000003 TV?: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+2Ew
00000004 AV?: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+30o
00000005 TV??ISO??: .byte ? # XREF: build_msg05_02_ReleaseBeforeData:loc_54462w
00000006 field_6: .byte ?
00000007 ISO_sure: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+D4w
00000008 field_8: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+DCw
00000009 LV_BV_char0: .byte ? # XREF: build_msg05_02_ReleaseBeforeData:loc_544F0w
0000000A LV_BV_char1: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+F6w
0000000B AE??: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+102o
0000000C field_C: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+120w # == 0x3
0000000D field_D: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1B8w
0000000E _PROP_AEB_div_3:.byte ? # XREF: build_msg05_02_ReleaseBeforeData+1BCw
0000000F _PROP_WBB_GM_div_3: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1C4w
00000010 _PROP_WBB_BA_div_3: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1CCw
00000011 _PROP_WBS_GM_div_3: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1D4w
00000012 _PROP_WBS_BA_div_3: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1DCw
00000013 field_13: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+1E4w
00000014 strobo_CMD_0xA9_response:.byte ? # XREF: build_msg05_02_ReleaseBeforeData+1ECw
00000015 field_15: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+23Aw
00000016 strobo_CMD_0xE6_Response_char01_b2b1b0_remapped:.byte ?
00000016 # XREF: build_msg05_02_ReleaseBeforeData+23Cw
00000017 field_17: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+244w
00000018 field_18: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+248w
00000019 PROP_LV_HALF_SHUTTER_bit0:.byte ? # XREF: build_msg05_02_ReleaseBeforeData+252w
0000001A temperature_plus_128: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+25Cw
0000001B Lens_attrib: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+26Cw
0000001B # build_msg05_02_ReleaseBeforeData+2A6w
0000001C _important_char0:.byte ? # XREF: build_msg05_02_ReleaseBeforeData+296w
0000001C # build_msg05_02_ReleaseBeforeData+2B4w ...
0000001D _important_char1:.byte ? # XREF: build_msg05_02_ReleaseBeforeData+29Cw
0000001D # build_msg05_02_ReleaseBeforeData+2B6w ...
0000001E _important_char2:.byte ? # XREF: build_msg05_02_ReleaseBeforeData:loc_546C0w
0000001E # build_msg05_02_ReleaseBeforeData+2C4o
0000001F Focal_Length: .half ? # XREF: build_msg05_02_ReleaseBeforeData+2C8o
0000001F # build_msg05_02_ReleaseBeforeData+2DEo
00000021 FocusPoint_bit_pattern:.half ? # XREF: build_msg05_02_ReleaseBeforeData+30Cw
00000021 # build_msg05_02_ReleaseBeforeData+312w
00000023 field_23: .byte ?
00000024 field_24: .byte ?
00000025 field_25: .byte ?
00000026 field_26: .byte ?
00000027 Metering_calculating_result_char00:.byte ?
00000027 # XREF: build_msg05_02_ReleaseBeforeData+31Cw
00000028 Metering_calculating_result_char01:.byte ?
00000028 # XREF: build_msg05_02_ReleaseBeforeData+324w
00000029 Metering_calculating_result_char02:.byte ?
00000029 # XREF: build_msg05_02_ReleaseBeforeData+32Cw
0000002A Metering_calculating_result_char03:.byte ?
0000002A # XREF: build_msg05_02_ReleaseBeforeData+334w
0000002B field_2B: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+33Aw # == 1
0000002C BOOL_unknown: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+348w
0000002D field_2D: .byte ? # XREF: build_msg05_02_ReleaseBeforeData+18w
0000002E Msg0502_ReleaseBeforeData ends
Msg0503_ReleaseAfter_Data struc # (sizeof=0x3D)
00000000 MsgHeader: struc_msg_header ? # == 0x3D , 0x5 , 0x3
00000003 field_3: .byte ?
00000004 field_4: .byte ?
00000005 CYC07_timing_counter_X_10:.word ? # XREF: build_msg05_03_ReleaseAfterData+6Co
00000009 PROP_AF_MODE: .byte ? # XREF: build_msg05_03_ReleaseAfterData+82w
0000000A field_A: .byte ? # XREF: build_msg05_03_ReleaseAfterData+90w
0000000B Image_orientation:.byte ? # XREF: build_msg05_03_ReleaseAfterData+98w
0000000C strobo_CMD_0xFC_response_char0:.byte ? # XREF: build_msg05_03_ReleaseAfterData+A6o
0000000D strobo_CMD_0xFC_response_char1:.byte ?
0000000E strobo_CMD_0xFC_response_char2:.byte ?
0000000F strobo_CMD_0xFC_response_char3:.byte ?
00000010 strobo_CMD_0xFC_response_char4:.byte ?
00000011 strobo_CMD_0xFC_response_char5:.byte ?
00000012 field_12: .byte ? # XREF: build_msg05_03_ReleaseAfterData+D4w
00000013 field_13: .byte ? # XREF: build_msg05_03_ReleaseAfterData+EAw
00000014 field_14: .byte ? # XREF: build_msg05_03_ReleaseAfterData+F8w
00000015 field_15: .byte ? # XREF: build_msg05_03_ReleaseAfterData+106w
00000016 field_16: .byte ? # XREF: build_msg05_03_ReleaseAfterData+110w
00000017 field_17: .byte ? # XREF: build_msg05_03_ReleaseAfterData:loc_54934w
00000018 field_18: .byte ? # XREF: build_msg05_03_ReleaseAfterData+166w
00000019 field_19: .byte ? # XREF: build_msg05_03_ReleaseAfterData+16Cw
0000001A Vfo1_div_4: .byte ? # XREF: build_msg05_03_ReleaseAfterData+17Ew
0000001B Vfo2_div_4: .byte ? # XREF: build_msg05_03_ReleaseAfterData+184w
0000001B # build_msg05_03_ReleaseAfterData+1BEo
0000001C vbat_noload_div_4:.byte ? # XREF: build_msg05_03_ReleaseAfterData+18Aw
0000001D vbat_bcon_div_4: .byte ? # XREF: build_msg05_03_ReleaseAfterData+190w
0000001E Aop_div_4: .byte ? # XREF: build_msg05_03_ReleaseAfterData+196w
0000001F Aop??_div_4: .byte ? # XREF: build_msg05_03_ReleaseAfterData+19Cw
00000020 battery_Resister_div4:.byte ? # XREF: build_msg05_03_ReleaseAfterData+1A2w
00000021 battery_remaining_capacity:.byte ? # XREF: build_msg05_03_ReleaseAfterData+1A8w
00000022 field_22: .byte ?
00000023 field_23: .byte ?
00000024 field_24: .byte ?
00000025 field_25: .byte ?
00000026 field_26: .byte ?
00000027 field_27: .byte ?
00000028 field_28: .byte ?
00000029 field_29: .byte ?
0000002A FocusDistance_first:.half ? # XREF: build_msg05_03_ReleaseAfterData+1CEw
0000002A # build_msg05_03_ReleaseAfterData+1D6w # from response half00 of Lens CMD 0xC2
0000002C FocusDistance_second:.half ? # XREF: build_msg05_03_ReleaseAfterData+1E0w
0000002C # build_msg05_03_ReleaseAfterData+1E8w # from response half02 of Lens CMD 0xC2
0000002E field_2E: .byte ? # XREF: build_msg05_03_ReleaseAfterData+1EEw # == 0
0000002F field_2F: .byte ? # XREF: build_msg05_03_ReleaseAfterData+B0w # == 0xC
00000030 TMRC_Capture03_timing_1st:.half ? # XREF: build_msg05_03_ReleaseAfterData+C0o
00000032 TMRC_Capture03_timing_2nd:.half ?
00000034 TMRC_Capture03_timing_3th:.half ?
00000036 TMRC_Capture02_timing_1st:.half ?
00000038 TMRC_Capture02_timing_2nd:.half ?
0000003A TMRC_Capture02_timing_3th:.half ?
0000003C dummy: .byte ? # XREF: build_msg05_03_ReleaseAfterData+22w
0000003D Msg0503_ReleaseAfter_Data ends
00000000 Metering_Row struc # (sizeof=0x12)
00000000 Pixel_00: .half ? # XREF: AE_action_API+17Cr
00000002 Pixel_01: .half ?
00000004 Pixel_02: .half ?
00000006 Pixel_03: .half ?
00000008 Pixel_04: .half ?
0000000A Pixel_05: .half ?
0000000C Pixel_06: .half ?
0000000E Pixel_07: .half ?
00000010 Pixel_08: .half ?
00000012 Metering_Row ends
00000000 half_7x9_Metering struc # (sizeof=0x7E)
00000000 Metering_Row0: Metering_Row ? # XREF: AE_action_API+17Cr
00000012 Metering_Row1: Metering_Row ?
00000024 Metering_Row2: Metering_Row ?
00000036 Metering_Row3: Metering_Row ?
00000048 Metering_Row4: Metering_Row ?
0000005A Metering_Row5: Metering_Row ?
0000006C Metering_Row6: Metering_Row ?
0000007E half_7x9_Metering ends
RAM:FFFFAE98 ADch02_Metering_LayerA:half_7x9_Metering <0> # DATA XREF: AE_action_API+1A8r
RAM:FFFFAE98 # AE_data_non_linear_converting+E2r ...
RAM:FFFFAE98 # from AD CH02
RAM:FFFFAF16 ADch02_Metering_LayerB:half_7x9_Metering <0>:3 # DATA XREF: AE_action_API+1C0r
RAM:FFFFAF16 # AE_data_non_linear_converting+12Ar ...
RAM:FFFFAF16 # from AD CH02
Based on known_spells.h , on 550D MCU side ，
if i'm not mistaken , MCU reports PROP 80030035 to CPU , which is equal to ( temperature + 128 ) inside Msg_03_0x38.
Nice find; on my startup logs, this property has values from 0x8c to 0xb5, most of them around 0x9a, and appears to be valid on all models.
TODO: cross-check this with temperature info written in EXIF.
Edit: in 500D firmware, this is called PROP_BOARD_TEMP. Greg found it a while ago:
Quote from: Greg on July 31, 2016, 04:16:29 PM
Video temperature :
mpu_recv(06 05 03 38 af 00) // 0xAF - 128 = 47°C
PROP_BOARD_TEMP 47Ž
550D MCU sends many structures to CPU with successive multi Msg03_0x32 (PROP 8003003A)
which is stated in known_spells.h , the following table is info of structures inside PROP 8003003A ,
each Msg03_0x32 contains of 0x32 bytes of payload of structures listed in TAB_Msg03_32_payload_info .
EDIT : Name in TAB_Msg03_32_payload_info is just the name of first byte of the structure , does't stands for
name of structure .
00000000 struc_23FC0 struc # (sizeof=0x8) # XREF: ROM:TAB_Msg03_32_payload_infor
00000000 SizeOfByte: .half ? # XREF: Report_Msg03_32+3Ar
00000002 SRC_Data_Location:.byte ? # 0 - RAM , 1 : EEPROM
00000003 unused_byte: .byte ?
00000004 RAM_ADDR: .word ? # offset
00000008 struc_23FC0 ends
00000000 struc_94 struc # (sizeof=0x8) # XREF: ROM:00024008r
00000000 SizeOfByte: .half ?
00000002 SRC_Data_Location:.byte ? # 0 - RAM , 1 : EEPROM
00000003 field_3: .byte ?
00000004 EEPROM_ADDR: .word ? # base 16
00000008 struc_94 ends
00023FC0 TAB_Msg03_32_payload_info:struc_23FC0 < 0x12, 0, 0, PROP_SHUTTER_bak00> # 0
ROM:00023FC0 struc_23FC0 < 8, 0, 0, PROP_SHUTTER_FFFFD7E4> # 1
ROM:00023FC0 struc_23FC0 < 0x1E, 0, 0, RAM00_struc_D7B0> # 2
ROM:00023FC0 struc_23FC0 < 0x1A, 0, 0, PROP_SHOOTING_MODE> # 3
ROM:00023FC0 struc_23FC0 < 0x1E, 0, 0, RAM01_struc_D7B0> # 4
ROM:00023FC0 struc_23FC0 < 4, 0, 0, Msg01_42_PROP_PHOTO_STUDIO_MODE> # 5
ROM:00023FC0 struc_23FC0 < 0x64, 0, 0, unk_FFFFD568> # 6
ROM:00023FC0 struc_23FC0 < 0x64, 0, 0, unk_FFFFD630> # 7
ROM:00023FC0 struc_23FC0 < 0x64, 0, 0, unk_FFFFD5CC> # 8
ROM:00024008 struc_94 < 0x12, 1, 0, 0x14D0> # 0
ROM:00024008 struc_94 < 8, 1, 0, 0x15C0> # 1
ROM:00024008 struc_94 < 0x1A, 1, 0, 0x1480> # 2
ROM:00024008 struc_94 < 0x1A, 1, 0, 0x1480> # 3
ROM:00024008 struc_94 < 0x1A, 1, 0, 0x1480> # 4
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1300> # 5
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1380> # 6
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1400> # 7
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1500> # 8
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1300> # 9
ROM:00024008 struc_94 < 0x64, 1, 0, 0x1300> # 0xA
ROM:00024008 struc_94 < 0x1E, 1, 0, 0x14A0> # 0xB
ROM:00024008 struc_94 < 0x1E, 1, 0, 0x14A0> # 0xC
ROM:00024008 struc_94 < 0x1E, 1, 0, 0x1580> # 0xD
Any info of pixel color pattern of AE CCD ?
Msg0303 is ERR code , Msg03_0x29 (PROP 80030023) is Err ClassID which may be remapped from ERR code .
On 550D MCU side , sub_0x376F8 sends and receives 16bits Command/Response to/from AF ccd .
in TX 16bits , bit15:bit13 looks like CMD code , bit12:bit0 is unknown .
Does anybody know the detailed info of AF CCD in550D ?
Is there anyway to decipher the MPU String in dm-log ?
I have a belief that the HDMI somehow uses the MPU
What I'm looking for is info on remove the black side bar on 5d2 in HDMI ,
In Liveview the side pillar bars in hdmi causing it to be downsize to 1650x1080
but I notice if I play back a H264 .Mov file in camera with HDMI connected to Ninja HDMI Harddrive recorder
I get full width (1920x1080) , so no more side pillar black bars
On exit of h264 .Mov file to Liveview , the pillar side bars return -- back to 1650x1080
So I run a dm-log build , basically connected hdmi then loaded a .mov with the play button
while the cam was logging , so the first one is before I plugged hdmi cable in , and it just repeated
4 "mpu send" & 1 "mpu recv" until I plugged in the hdmi
446F4> PropMgr:00096948:00:00: *** mpu_send(26 24 09 17 ca 01 e5 00 ee 2b 00 00 b0 21 00 00 1d 12 00 00 97 01 a0 00 00 00 00 00 00 00 00 00 00 00 98 19 00), from ff861a88
81766> PropMgr:00096948:00:00: *** mpu_send(26 24 09 17 a7 01 d3 00 ab dd 00 00 88 7c 00 00 59 4b 00 00 b8 00 5f 00 00 00 00 00 00 00 00 00 00 00 17 00 00), from ff861a88
BE98A> PropMgr:00096948:00:00: *** mpu_send(26 24 09 17 ec 01 f6 00 6b 5d 00 00 18 35 01 00 6a aa 00 00 d2 01 ea 00 00 00 00 00 00 00 00 00 00 00 98 19 00), from ff861a88
FBA69> PropMgr:00096948:00:00: *** mpu_send(26 24 09 17 c4 01 e2 00 3a 2b 00 00 f7 8c 00 00 18 59 00 00 5c 01 b8 00 00 00 00 00 00 00 00 00 00 00 98 19 00), from ff861a88
2362E> **INT-36h*:000969b4:00:00: *** mpu_recv(06 05 03 17 a5 00), from ff99f6cc
When I plugged in the hdmi cable I got
2 "mpu send" & 1 "mpu recv" , and it just cycle with the 2 send & 1 recv
83424> PropMgr:00096948:00:00: *** mpu_send(0c 0a 09 0a 71 6e 01 29 54 65 00), from ff861a88
8374A> PropMgr:00096948:00:00: *** mpu_send(08 07 09 04 29 00 01 00), from ff861a88
83E01> **INT-36h*:000969b4:00:00: *** mpu_recv(0a 09 09 10 71 54 65 6d 6d 00), from ff99f6cc
Edit: here the log file
mpu_hdmi_review_h264-5d2-dm-0001.log (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/mpu_hdmi_review_h264-5d2-dm-0001.log)
Did a little more reading searching , found a link to mpu-communication (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-mpu-communication) in qemu source
QuoteThe message sent by the main CPU is:
06 04 02 00 00 00
•06 is message size (always even)
•04 is payload size (always message_size - 1 or message_size - 2)
•02 00 00 00 is the payload:◦02 00 identifies the message (look it up in known_spells.h)
◦the last 00 means no special confirmation was requested (Complete WaitID string)
◦the remaining 00 may contain
If I fellow this example ,
83E01> **INT-36h*:000969b4:00:00: *** mpu_recv(0a 09 09 10 71 54 65 6d 6d 00), from ff99f6cc1st set of number "0a"=10> even
2nd set : "09" payload size -1 , ok good so far so good
3rd set of numbers "09 10 71 54" is the payload
"09 10" are define in the know_spells.h (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/known_spells.h?fileviewer=file-view-default)
{ 0x09, 0x10, 0x80050010, "PROP_BV" } (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/known_spells.h?fileviewer=file-view-default#known_spells.h-301)
Don't know what "Prop_BV" is but there is for sure HDMI spells too -- more research
Quote from: reddeercity on December 16, 2018, 04:32:59 AM
Is there anyway to decipher the MPU String in dm-log ?
Of course (https://www.magiclantern.fm/forum/index.php?topic=17596.msg198329#msg198329), here's a short example:
cd qemu-eos/qemu-2.5.0/hw/eos/mpu_spells/
python annotate_mpu_log.py 5D2 /path/to/logfile.log
From your log, it just shows regular LiveView activity, nothing unusual.
0E91F> PropMgr:00096948:00:00: *** mpu_send(06 04 09 00 00), from ff861a88 ; PROP_LV_LENS
0FB36> **INT-36h*:000969b4:00:00: *** mpu_recv(3e 3c 09 00 bb 93 40 00 be 8e a0 00 bd c3 00 00 3b c0 a0 00 00 00 00 00 bd ea 60 00 ba 9f 40 00 00 00 00 00 00 00 08 10 21 20 50 64 00 26 51 66 00 18 00 56 00 4e 00 00 00 81 00 00 00), from ff99f6cc ; PROP_LV_LENS
234B4> PropMgr:00096948:00:00: *** mpu_send(0c 0a 09 0a 71 6e 01 29 54 65 00), from ff861a88 ; PROP_LV_BV
23816> PropMgr:00096948:00:00: *** mpu_send(08 07 09 04 29 00 01 00), from ff861a88 ; PROP_LV_APERTURE
23F63> **INT-36h*:000969b4:00:00: *** mpu_recv(0a 09 09 10 71 54 65 6d 6d 00), from ff99f6cc ; PROP_BV
2424E> **INT-36h*:000969b4:00:00: *** mpu_recv(0a 08 09 05 00 81 00 00 00), from ff99f6cc ; PROP_LV_LENS_STABILIZE
3C5DA> PropMgr:00096948:00:00: *** mpu_send(26 24 09 17 f7 01 fb 00 03 c7 00 00 41 a3 01 00 9a d8 00 00 d9 01 ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00), from ff861a88 ; PROP_LV_FOCUS_DATA
...
Quote
I have a belief that the HDMI somehow uses the MPU
I have a strong belief it does not. I'm not sure if it's even aware of whether an external monitor is connected, but need to double-check.
The HDMI chip appears to use I2C (https://www.magiclantern.fm/forum/index.php?topic=21573), but I did not attempt to understand what exactly it does. I'm pretty sure there's a lot of interesting stuff there, but it's not my primary focus (at least for now).
Thanks for the pointers , yes I see you're right I forgot about HDMI I2C communication thread
still good to learn about MPU & spells , helps me understand more :D
Quote from: a1ex on June 25, 2017, 04:42:24 PM
On some models (those with TX19A (https://photo-parts.com.ua/parts/?part=TMP19A43) MPU), you can read the EEPROM, with the mpu_dump module. The 70D is not one of them - it uses F74966A (https://photo-parts.com.ua/parts/?part=F74966A), just like 100D and 700D. The 5D3 and 6D use F74965A (https://photo-parts.com.ua/parts/?part=F74965A), while the 650D and EOSM use F74964A (https://photo-parts.com.ua/parts/?part=F74964A).
From here (https://insight.rpxcorp.com/litigation_documents/11263309):
Quote
[...] Renesas SH7231 series microcontrollers (also known as the Renesas semiconductor component with the package marking "F74966A" or the die marking "R5F72315A") [...]
=> hardware manual (https://www.renesas.com/sg/en/doc/products/mpumcu/doc/superh/r01uh0073ej0200_sh7231.pdf).
Another mystery cleared, thanks Danieel 8)