Messages

I've used Kicad for cable and dev board. You can find the project and gerber files here:
https://github.com/coon42/magic-lantern-dev-kit

The latest commit does already contain a fix for the MPU TX pin, so a manual fix via jumper wire is not needed anymore.

If I don't have a lens attached or when lens is at widest possible aperture I don't hear anything when pressing the shutter button.

[sht_EnableManualSilent]

Executing sht_EnableManualSilent on UART gives the following output:

Code Select Expand


K433[1]>sht_EnableManualSilent
Enable Names
    "SHOOT"
    "LV"
    "MECHA"
    "LENS"
    "EF"
    "APEX"
    "DC_MECHA"
    "FA"
    "IS"
    "LVAF"
    "EOSAF"
    "EOSAE"
    "EDET"
    "ALL"

Stab Status
    SHOOT : respect
    LV : respect
    MECHA : ignore
    LENS : respect
    EF : respect
    APEX : respect
    DC_MECHA : ignore
    FA : ignore
    IS : ignore
    LVAF : respect
    EOSAF : ignore
    EOSAE : ignore
    EDET : respect

sht_EnableManualSilent returned 0(0x0)


When pressing the shutter button in manual mode an image is taken but shutter does not close. Camera is in electronic shutter mode.

Executing sht_DisableManualSilent on UART gives the following output:

Code Select Expand


K433[1]>sht_DisableManualSilent
Enable Names
    "SHOOT"
    "LV"
    "MECHA"
    "LENS"
    "EF"
    "APEX"
    "DC_MECHA"
    "FA"
    "IS"
    "LVAF"
    "EOSAF"
    "EOSAE"
    "EDET"
    "ALL"

Stab Status
    SHOOT : respect
    LV : respect
    MECHA : respect
    LENS : respect
    EF : respect
    APEX : respect
    DC_MECHA : ignore
    FA : ignore
    IS : ignore
    LVAF : respect
    EOSAF : ignore
    EOSAE : ignore
    EDET : respect

sht_DisableManualSilent returned 0(0x0)


Shutter does close again in manual mode.

When pressung shutter button in Bulb mode while beeing in Silent Shutter mode camera crashes with Err70 and asserts on UART:

Code Select Expand


K433[1]>    45024: 711030.598 [STARTUP] ERROR <7>ASSERT : ImageController::ImageControllerShootCommon.c
    45025: 711030.621 [STARTUP] <7>ASSERT : Task = ShootCapture
    45026: 711030.626 [STARTUP] <7>ASSERT : Core 0
    45027: 711030.633 [STARTUP] <7>ASSERT : Line 813
    45028: 711030.640 [STARTUP] < StackDump >
    45029: 711030.644 [STARTUP] SP: 0x00245174
    45030: 711030.674 [STARTUP] 0xFFFFFFFF
    45031: 711030.679 [STARTUP] 0x00000064
    45032: 711030.682 [STARTUP] 0x00000000
    45033: 711030.693 [STARTUP] 0x40D65130
...


When pressing the shutter button in Bulb mode while in normal shutter mode you can hear some mechanical movement inside the camera before the image capturing starts, even when having the lens on the widest possible aperture and also when not having a lens attached at all. I don't know what is exactly happing here but I assume that the camera cannot move the required part for bulb mode when beeing in silent shutter mode. It does detect that and does crash.

[0xE03B4FDC]

I have found a function which is used to set some GPIO pins at 0xE03B4FDC.

Signature is:

Code Select Expand


void gpioSet(int gpioOffset, int onOffBitmask)


gpioOffset is added to the fixed address 0xD0130000.
onOffBitmask is mostly 0x4D0002 to set the GPIO and 0x4C0003 to reset the GPIO. Bitmasks are different on some addresses.

The function is used to toggle GPIO pins, and some chip enable pins. It is also used to toggle some GPIO pin to low at the end of send_mpu which meight be an interrupt pin for MPU. This function may be used to identify several GPIOs.

[Update:]

Crosspost from https://www.magiclantern.fm/forum/index.php?topic=22770.msg233318#msg233318:

Code Select Expand


'Get R6 LED base

private sub save_led_base(fileName)
  RemoveFile(fileName)

  f = OpenFileCREAT(fileName)
  CloseFile(f)

  f = OpenFileWR(fileName)

  pLedBase = 0x4F54
  WriteFileString(f, "LED base 1: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)

  pLedBase = 0x4F5C
  WriteFileString(f, "LED base 2: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)

  CloseFile(f)
end sub

private sub Initialize()
  save_led_base("B:/LED_BASE.TXT")
end sub


Could someone with a R6 execute this and tell me the result?

Update: yourboylloyd did run this on his R6 and got the following result:

Code Select Expand


[0x01A14B24] LED 0: 0xD22390C2
[0x01A14B48] LED 1: 0xD2239000
[0x01A14B6C] LED 2: 0xD22393FC
[0x01A14B90] LED 3: 0xD2239000
[0x01A14BB4] LED 4: 0xD2239001
[0x01A14BD8] LED 5: 0xD2238F00
[0x01A14BFC] LED 6: 0xD223900B
[0x01A14C20] LED 7: 0xD2239037
[0x01A14C44] LED 8: 0xD2239000
[0x01A14C68] LED 9: 0xD2239001
[0x01A14C8C] LED 10: 0x30218F00
[0x01A14CB0] LED 11: 0xD223900B
[0x01A14CD4] LED 12: 0xD2239037
[0x01A14CF8] LED 13: 0xD2239000
[0x01A14D1C] LED 14: 0xD2239001
[0x01A14D40] LED 15: 0xD2238700
[0x01A14D64] LED 16: 0xD223900B
[0x01A14D88] LED 17: 0xD2239037
[0x01A14DAC] LED 18: 0xD2239000
[0x01A14DD0] LED 19: 0xD2239001
[0x01A14DF4] LED 20: 0xD2238F00
[0x01A14E18] LED 21: 0xD223900B
[0x01A14E3C] LED 22: 0xD2239037
[0x01A14E60] LED 23: 0xD2239000
[0x01A14E84] LED 24: 0xD2239001
[0x01A14EA8] LED 25: 0xD2238F00
[0x01A14ECC] LED 26: 0xD223900B
[0x01A14EF0] LED 27: 0xD2239037
[0x01A14F14] LED 28: 0xD2239000
[0x01A14F38] LED 29: 0xD2239001
[0x01A14F5C] LED 30: 0xD2238F00
[0x01A14F80] LED 31: 0xB24F797D
[0x01A14FA4] LED 32: 0xD2238DFF
[0x01A14FC8] LED 33: 0xD3C4DFA0
[0x01A14FEC] LED 34: 0xD2239000
[0x01A15010] LED 35: 0xB24F797D
[0x01A15034] LED 36: 0xD2238FFF
[0x01A15058] LED 37: 0xD3C4E030
[0x01A1507C] LED 38: 0xD2239000
[0x01A150A0] LED 39: 0xB24F797D
[0x01A150C4] LED 40: 0xD2238FDD
[0x01A150E8] LED 41: 0xD3C4E0C0
[0x01A1510C] LED 42: 0xD2239000
[0x01A15130] LED 43: 0xB24F797D
[0x01A15154] LED 44: 0xD0238BDF
[0x01A15178] LED 45: 0xD3C4E150
[0x01A1519C] LED 46: 0xD2239000
[0x01A151C0] LED 47: 0xB24F797D
[0x01A151E4] LED 48: 0xD0238FFF
[0x01A15208] LED 49: 0xD3C4E1E0
[0x01A1522C] LED 50: 0xD2239000
[0x01A15250] LED 51: 0xB24F797D
[0x01A15274] LED 52: 0xD2238FFF
[0x01A15298] LED 53: 0xD3C4E270
[0x01A152BC] LED 54: 0xD2239000
[0x01A152E0] LED 55: 0xB24F797D


Card LED address is probably 0xD22390C2 on R6 but I am a bit confused why there are 56 possible LEDs...

[led.set.directly]

I have found a firmware version independent and read only method to find LED GPIO addresses of newer camera models and created a little Canon Basic script for that.
Sample usage for RP:

Code Select Expand


'LED GPIO dumper for EOS RP
dim gpio_base      = 0xD0130000
dim led_obj_ptr    = 0x4E28
dim led_obj_offset = 0x28
dim led_count_max  = 15

private sub save_led_gpio_addresses(fileName)
  RemoveFile(fileName)

  f = OpenFileCREAT(fileName)
  CloseFile(f)

  f = OpenFileWR(fileName)
  pLedObjectBase = *led_obj_ptr

  ledKind = 0

  do while ledKind < led_count_max
    pLedObject = pLedObjectBase + ledKind * led_obj_offset
    ledGpioOffset = pLedObject + 8

    WriteFileString(f, "[0x%08X] LED %d: 0x%08X\n", pLedObject, ledKind, gpio_base + *ledGpioOffset)
    ledKind = ledKind + 1
  loop

  CloseFile(f)
end sub

private sub Initialize()
  save_led_gpio_addresses("B:/LED_GPIOS.TXT")
end sub


The script saves the following content:

Code Select Expand


[0x00D2DE8C] LED 0: 0xD01300D4
[0x00D2DEB4] LED 1: 0xD0130000
[0x00D2DEDC] LED 2: 0xD01300D8
[0x00D2DF04] LED 3: 0xD0130000
[0x00D2DF2C] LED 4: 0xD0130000
[0x00D2DF54] LED 5: 0xD0130000
[0x00D2DF7C] LED 6: 0xD01300DC
[0x00D2DFA4] LED 7: 0xD0130000
[0x00D2DFCC] LED 8: 0xD0130000
[0x00D2DFF4] LED 9: 0xD0130000
[0x00D2E01C] LED 10: 0xD0130000
[0x00D2E044] LED 11: 0xD0130000
[0x00D2E06C] LED 12: 0xD0130000
[0x00D2E094] LED 13: 0xD0130000
[0x00D2E0BC] LED 14: 0xD0130000


The output suggests that there are three LEDs on RP (four LEDs if you also count the addresses ending with 0).

Code Select Expand


LED 0: 0xD01300D4 - Card LED
LED 2: 0xD01300D8 - Auto Focus Assist LED
LED 6: 0xD01300DC - Unknown / Nothing happens
Other LEDs: 0xD0130000 - Unknown / Nothing happens


Writing to these addresses will toggle the LEDs.
Values to toggle GPIOs on RP are:

Code Select Expand


LED_ON_BITMASK:  0x4D0002
LED_OFF_BITMASK: 0x4C0003


The script can also be run on other newer models. One has to find and set the following parameters for their camera model:

Code Select Expand


gpio_base
led_obj_ptr
led_obj_offset
led_count_max


The parameters can be found by inspecting led.set.directly function which can be found at 0xE0697DAA on RP 1.6.0 firmware. The function may also be named LEDDrv_SetLEDDirectly on other models.

Function signature is:

Code Select Expand


int led_set_directly(uint ledKind, int controlId)


Parameters for EOS R are:

Code Select Expand


'LED GPIO dumper for EOS R
dim gpio_base      = 0xD0130000
dim led_obj_ptr    = 0x4DDC
dim led_obj_offset = 0x24
dim led_count_max  = 13


Script from above with these values produces:

Code Select Expand


[0x00D7D7B4] LED 0: 0xD01300D4
[0x00D7D7D8] LED 1: 0xD0130000
[0x00D7D7FC] LED 2: 0xD01300D8
[0x00D7D820] LED 3: 0xD0130000
[0x00D7D844] LED 4: 0xD0130000
[0x00D7D868] LED 5: 0xD0130000
[0x00D7D88C] LED 6: 0xD0130000
[0x00D7D8B0] LED 7: 0xD0130000
[0x00D7D8D4] LED 8: 0xD0130000
[0x00D7D8F8] LED 9: 0xD0130000
[0x00D7D91C] LED 10: 0xD0130000
[0x00D7D940] LED 11: 0xD0130000
[0x00D7D964] LED 12: 0xD0130000


GPIO addresses are similiar to RP but LED 6 does also end with 0 here.

However, it's not trivial to get the values for R6 since the value for gpio_base is stored in RAM.
Could someone with an R6 execute this and tell me the result?

Code Select Expand


'Get R6 LED base

private sub save_led_base(fileName)
  RemoveFile(fileName)

  f = OpenFileCREAT(fileName)
  CloseFile(f)

  f = OpenFileWR(fileName)

  pLedBase = 0x4F54
  WriteFileString(f, "LED base 1: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)

  pLedBase = 0x4F5C
  WriteFileString(f, "LED base 2: [0x%08X]: 0x%08X\n", pLedBase, *pLedBase)

  CloseFile(f)
end sub

private sub Initialize()
  save_led_base("B:/LED_BASE.TXT")
end sub


This Canon Basic script enables silent shutter on RP:

Code Select Expand

private sub Initialize()
    ExecuteEventProcedure("sht_EnableManualSilent")
end sub
Works in M, Av, Tv and P both in single and continuous modes. Works fine with interval timer. Fails with ERR70 in bulb.

Nice finding! It seems we have a first feature for RP . Usually silent shutter is only possible in SCN mode or when performing a focus bracketing shoot but not in any other modes.
When do you get ERR70 in bulb? Directly after shutter press or when it tries to close the shutter?

No, please no! Why does so many hardware gets ruined by these touch "innovations" these days? I can't imagine that a touch button will give a good feedback as a physical button does.

[SaveVRAM]

All information in this post do refer to EOS RP with firmware 1.6.0.

I have done some further investigations on VRAM handling and it seems that Canon has changed it on newer models. On my initial investigations I have done a full RAM dump and searched for the MARV signatures manually to find the VRAM buffers. This worked fine as a first entry point to draw simple things on the LCD but drawing in EVF or HDMI output did not work properly with this method. Therefore I have analysed the SaveVRAM event procedure to find out some more information about the buffer handling.

In the past the structure of struct bmp_vram_info was like this:

Code Select Expand


struct bmp_vram_info
{   
    struct MARV * vram1;        /* one of the two bitmap buffers - statically allocated? */
    struct MARV * vram2;        /* the other bitmap buffer */
    struct MARV * back_vram;    /* we need to write to the other one */
};


vram1 and vram2 are two buffers which are written in an alternating way to prevent flicker.
back_vram points to the back buffer.

On RP Canon has changed it to this:

Code Select Expand


struct bmp_vram_info
{   
    struct MARV * vram1;        /* one of the two bitmap buffers - statically allocated? */
    struct MARV * vram2;        /* the other bitmap buffer */
};


Plus now there is a global buffer index at 0xFF6C with the index of the current back buffer. It is either 0 or 1.

There are 3 YUV (UYVYAA) buffer pairs in total. One back and one front buffer each. Only one of the three buffer pairs seems to used:

Code Select Expand


vramBufferPairNo = 0: Final image displayed on LCD or EVF without sensor image
vramBufferPairNo = 1: Nullptr (Unknown)
vramBufferPairNo = 2: Nullptr (Unknown)


I don't know if buffer pairs 1 and 2 are ever used.

Formular for getting YUV buffers:

Code Select Expand


DAT_e0255238 + vramBufferPairNo * 0x28 + (1 - vram_current_buffer) * 4 - 0x5c


DAT_e0255238 is the dereferenced value on address 0xE0255238 which is 0x722B0.
vramBufferPairNo selects the buffer pair. Valid values are 0 to 2. It seems that buffer 1 and 2 are unused.
vram_current_buffer is the dereferenced value of 0xFF6C and is either 0 or 1.

There are 6 BGRA buffers in total. They are not double buffered and only two them are used in practice:

Code Select Expand


vramBufferNo = 0: Menu and Live View Overlays
vramBufferNo = 1: Focus point overlay
vramBufferNo = 2: Nullptr (Unknown)
vramBufferNo = 3: Nullptr (Unknown)
vramBufferNo = 4: Nullptr (Unknown)
vramBufferNo = 5: Nullptr (Unknown)


Formular for getting BGRA buffers:

Code Select Expand


DAT_e0331888 + vramBufferNo * 0xc



With this information I am now able to draw proper images on LCD, EVF and HDMI output. However, due to the pixel wise "software" rendering via CPU the current rendering performance with about 3 fps is quite bad.
I assume that actual rendering by Canon code is done in the BGRA buffers and are then composited and converted to YUV by some coprocessor. I don't know how to trigger that conversion in Canon firmware. Once I have found that out rendering speed should increase significantly. Until full ML does not run on RP, speed is not in focus so I will keep it like that for now.

Bad news are, that the new VRAM handling does require some adjustment in ML code. Good news are that R5 and R6 do also seem to use this new rendering method so they will profit from these changes as well. EOS R does still use the old method.

[Arg Name]

I have found the functions for creating a category and an entry for drysh on EOS RP:

Code Select Expand


int drysh_add_category(char* pCategoryName);




 
 

Arg Name	Description
pCategoryName	name of the category which is displayed in the help menu

returns the ID of the created category.

Code Select Expand


int drysh_add_command(int categoryId, void* pNullUnknown, char* pName, void* pFunction, char* pUsageInfo);




 
 
 
 
 
 

Arg Name	Description
int categoryId	The category where the entry shall be added
void* pNullUnknown	Unknown. Is always set to 0 by canon code in RP firmware.
char* pName	Name of the command
void* pFunction	Function pointer to the function which the command will execute
char* pUsageInfo	Optional Information which is displayed when typing help <command>

returns the id of the entry.

Function pointer definitions (for EOS RP firmware 1.6.0):

Code Select Expand


int (*drysh_add_category)(char *pCategoryName) = 0xe06687b5;
int (*drysh_add_command)(int categoryId, void *pNullUnknown, char *pName, void *pFunction, char *pUsageInfo) = 0xe06688d5;


And here is some example code which shows how to use it:

Code Select Expand


// This function is passed to drysh_add_command() and called when executing ml_version command on drysh:
void ml_version() {
  uart_printf("Camera: EOS RP Firmware 1.6.0\nMagic Lantern: 0.1 (pre alpha)\n");
}

void magic_lantern_task() {
...
const int categoryId = drysh_add_category("Magic Lantern"); // Create a Magic Lantern category
drysh_add_command(categoryId, 0, "ml_version", ml_version, "Displays version information of Magic Lantern."); // Create a ml_version entry
...
}


On the UART shell it looks like this when beeing in drysh:

Code Select Expand


K433[1]>Dry[WarpPUX]> ?
[Kern]
extask  memmap  meminfo  mkcfg  dminfo  exobjinfo  stdlibcfg  efatcfg
sysvers  xd  xm  prio  resume  suspend  release  sem  mutex  event  mq  exit
[Utility]
uart_change
[Magic Lantern]
ml_version

Dry[WarpPUX]> help ml_version
ml_version : Displays version information of Magic Lantern.
Dry[WarpPUX]> ml_version
Camera: EOS RP Firmware 1.6.0
Magic Lantern: 0.1 (pre alpha)


That way we can register our own debugging functions now.

[1.6.0.0110(0a)]

Code Select Expand


K433[1]>eep_read 0 0x8000
[Notice] Target is Not EEP_2ND

address   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00000000 00 AA 00 AA FF FF FF FF D0 44 00 00 00 80 00 00
00000010 00 AA 00 AA FF FF FF FF BC 00 00 00 00 01 00 00
00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
...


Does a hex dump from a region of the ICUs EEPROM. First argument is start address, second argument is end address.
Addresses are decimal by default. When adding a 0x prefix, numbers are interpreted as hex values.

A full EEPROM dump of EOS RP can be done by executing the command from above (range from 0 to 0x8000).

Reading memory after 0x8000 will make the camera crash and cameras display will show error 70.
Camera must be reset by a battery pull then:

Code Select Expand


K433[1]>eep_read 0x8000 0x9000
[Notice] Target is Not EEP_2ND

address   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00008000 00      3468: 216045.037 ERROR [EEP ERROR] ReadEEPROM : Unavailable Address !!
     3469: 216045.188 [STARTUP] ERROR ASSERT : Device::eeprom.c
     3470: 216045.210 [STARTUP] ASSERT : Task = EvShel
     3471: 216045.216 [STARTUP] ASSERT : Core 0
     3472: 216045.220 [STARTUP] ASSERT : Line 1419
     3473: 216045.227 [STARTUP] < StackDump >
     3474: 216045.230 [STARTUP] SP: 0x00268294


Therefore the size of ICUs EEPROM of EOS RP is 32KB.

Content of EEPROM is unknown yet. Readable content I have found is:

- Version information of ICU and MPU: 1.6.0.0110(0a)
- address of canons cloud service: jp.co.canon.ic.cameraconnect. Replacing this address in EEPROM could make it possible to let the camera connect to somewhere else.
- last used lens: EF50mm f/1.8 STM

However, I didn't find some expected values like shutter count or wifi passwords.
On every read of the EEPROM the message [Notice] Target is Not EEP_2ND is displayed. This implies, that there is a second EEPROM somewhere.

[?]

I have found out by accident that the shell has some form of "tab completion" by typing a partial command and ending it with a ?:

Code Select Expand


K433[1]>eep_?
[eep_erase]
[eep_forcefrom_service]
[eep_forcefrom_ring]
[eep_boot_change_ring]
[eep_force_sync]
[eep_force_read]
[eep_write]
[eep_sync]
[eep_write_single]
[eep_read]
[eep_show_service]
[eep_boot_change_service]
[eep_boot_check]


Code Select Expand


K433[1]>eep_for?
[eep_forcefrom_service]
[eep_forcefrom_ring]
[eep_force_sync]
[eep_force_read]


If there is only one result found it will be autocompleted in the prompt so you can just hit enter to execute:

Code Select Expand


K433[1]>Cam?
[CamInfo_Debug]
K433[1]>CamInfo_Debug



[akashimorino]

When akashimorino is entered, the NewTaskShell command is registred as Event Procedure, and is executed. (Event Procedures are these functions which can be called by Canon Basic for example.)
NewTaskShell does spawn a EvShell (Event Shell) task and the well known prompt appers:

Code Select Expand


K433[1]>


When executing NewTaskShell while there is already a prompt, another EvShell Task is spawned and the following does happen:

Code Select Expand


K433[1]>NewTaskShell
Change Console K433[1]> To K433[2]>...


The number between the brackets is increased and does threfore show how many shell tasks are currently running:

Code Select Expand


K433[2]>NewTaskShell
Change Console K433[2]> To K433[3]>...


With quit command, all shells can be closed again:

Code Select Expand


K433[3]>quit
Quiting event shell...
Change Console K433[3]> To K433[2]>...

K433[2]>quit
Quiting event shell...
Change Console K433[2]> To K433[1]>...

K433[1]>quit
Console All Closed


It might be possible to switch between the shells somehow but I don't understand what the benefit of this would be. There meight be a feature we don't know about yet.

Yep, exiftool worked.

In point of time a picture was taken MPU said:

Code Select Expand


Battery    : 0x03D3
TEMP(MAIN) : 0x2120 (33.1deg)
TEMP(SH)   : 0x1EFF (30.9deg)
TEMP(A)    : 0x2760 (39.3deg)
TEMP(BACK) : 0x1B00 (27.0deg)


EXIF said:

Code Select Expand


Camera Temperature    39 C


Therefore the value of TEMP(A) is taken for EXIF.

It would be interesting to know which temperature value can be found in the EXIF data of the RAW file.

I am using RAW Therapee which cannot read EXIF data from CR3 RAW files which are used on newer canon models. Therefore I cannot answer that right now. If someone knows another free tool which can do that, please let me know!

Completly my fault. I extrapolated TX line based on testpads on PCB, never got a prompt on R.
Lesson learned: never trust random guy in internet, even if he seems to know what's he's doing 

No worries, it is undocumented hardware and mistakes do happen. Without your post about the existence of the connector I wouldn't have built the cable + dev kit and wouldn't have such a huge progress as I have right now.

With so many discoveries, i think this is separate thread(s) worthy? One for drysh on Digic8 and one for MPU. I think nobody dug into MPU that far yet.

Good point. I may also create some pages on the wiki about my findings.

Architecture of MPU is 32 bit ARMv7 (little endian) like ICU. Therefore it is not TX19a / MIPS anymore.
Base address of MPU firmware image is 0x20000000.

It looks like that a minimal version of DryOS is running on MPU. I think it should be possible to emulate MPU in qemu now.
We may also abuse the MPUs update mechanism to boot up some MPU version of ML and start our own tasks there, if we should ever be in need for that.

[Be careful not to type MEMW by accident, which will overwrite data in RAM and may lead to undefined behaviour of the MPU! This meight destroy hardware components in worst case.]

Code Select Expand


MEMR 0 FFFFF


Does a hex dump from a region of the MPUs memory. First argument is start address, second argument is number of bytes to read.
Maximum value allowed for second argument is FFFFF.

When executing the command above, the complete firmware of MPU is dumped, since firmware is mapped to 0.
From address ~0x60000 to 0xFFFFF data bytes are all 0xFF on EOS RP and do not need to be dumped.

The firmware of MPU on EOS RP can be dumped by executing the following command:

Code Select Expand


MEMR 0 60000


Be careful not to type MEMW by accident, which will overwrite data in RAM and may lead to undefined behaviour of the MPU! This meight destroy hardware components in worst case.

[0x800]

Code Select Expand


MON>>>EEPR 0 1000
address   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00000000 0A FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
...


Does a hex dump from a region of the MPUs EEPROM. First argument is start address, second argument is end address.
When dumping from 0x0 to 0x1000, hex data is not displayed anymore after 0x7FF:

Code Select Expand


...
000007E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000007F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000800                                               
00000810                                               
00000820                                               
00000830                                               
00000840                                               
00000850
...


Therefore MPUs EEPROM has a size of 0x800 Bytes (2KB).
A full EEPROM dump can be done by executing:

Code Select Expand


EEPR 0 7FF


Be careful not to type EEPW by accident, which will overwrite data in the EEPROM and may render the MPU unbootable!

The content of the EEPROM is unknown yet. It does probably contain user settings.

Code Select Expand


MON>>>SW

LockSw                        : UnLock(On)
LockSw(Raw)                   : UnLock(On)
CardCover                     : Open
CardCover(Raw)                : Open
BatCover                      : Close
BatCover(Raw)                 : Close
CF2DetectSw                   : On
ELButton                      : Off
SubDialLockSw                 : Off
Sw1                           : Off
Sw2                           : Off
AELockButton                  : Off
AFStartButton                 : Off
AFFrameSelectButton           : Off
MIFSw                         : Off
ShotModeButton                : Off
M                             : Off
SetButton                     : Off
MenuButton                    : Off
PlayButton                    : Off
InfoButton                    : Off
EraseButton                   : Off
LvMovieStartButton            : Off
NFCDetectSw                   : Off
BLEDetectSw                   : Off
CrossUp                       : Off
CrossDown                     : Off
CrossRight                    : Off
CrossLeft                     : Off
MainDial                      : 0
SubDial                       : 0
ModeDial[d3,d2,d1,d0]         : 1 0 1 1


Displays the current state of all switches.
I may also use this naming convention for the MPU button codes I have found earlier.

Sw2 = Half Shutter
Sw1 = Shutter

MainDial and SubDial values are stored as absolute values and do count from 0 after boot.

Code Select Expand


MON>>>I2C

Usage: i2c set   channel prs clk slaveaddr
Usage: i2c write channel addr data [data]
Usage: i2c read  channel count
Usage: i2c read  channel addr count


Can possibly be used to send arbitrary data to the cameras I2C devices. Since I don't know which devices are connected to I2C nor which addresses they have and what commands they do expect, I won't touch this for now.

Code Select Expand


MON>>>TEMPINFO
Battery    : 0x01D4
TEMP(MAIN) : 0x2370 (35.4deg)
TEMP(SH)   : 0x227F (34.4deg)
TEMP(A)    : 0x2BF0 (43.9deg)
TEMP(BACK) : 0x1DB0 (29.6deg)


Displays the values of several temperature sensors. TEMP(A) seems to be the sensor of the main CPU.
When recording a video in 4K @ 25fps on RP, temperature rises over 53C° but I have stopped this after some minutes and may do a long term test later to find out where the temperature maxes out.

Someone with an R5 may try this while doing 8K recording to find out at which temperature the camera is shut down.

Code Select Expand


MON>>>STACKINFO
Sw Task Stack Info addr=0x20008C98 size=500 used=448
Main Task Stack Info addr=0x20006FC8 size=660 used=552
Batt Task Stack Info addr=0x20008450 size=1200 used=604
Temp Task Stack Info addr=0x20007268 size=752 used=436
Acc Task Stack Info addr=0x20007560 size=640 used=460
Disp Task Stack Info addr=0x200077E8 size=640 used=404
Adapter Task Stack Info addr=0x20007A70 size=600 used=412
Log Task Stack Info addr=0x20007CD0 size=660 used=408
Monitor Task Stack Info addr=0x20008E98 size=1340 used=536
Idle Task Stack Info addr=0x20008908 size=900 used=432
(null) Task Stack Info addr=0x200093E0 size=500 used=280


Some info about the stack of all running tasks.

Code Select Expand


MON>>>BCINFO
BC Result
Battery   :Li-ion
Vop       :0276
Vbc       :0258
Iop       :002A
Ibc       :00D3
R         :2D719
R(ohm)    :0024
Vfo1      :0229
Vfo2      :0000
VfoSt     :0229
VfoMotor  :0229


Starts periodic logging of charge / discharge status of the battery.

Code Select Expand


MON>>>BATTINFO

TYPE   :00
NAME   :000000004C502D453137
BNO    :248A0228
FCB    :0442
RV     :1C20
RSVD1  :0000
CYCNT  :0011
CERCNT :00
CARCNT :00
CCNT   :000475
RSVD2  :00000000


Shows information about the battery. Does output nothing, when an AC adapter is used.

Code Select Expand


MON>>>INDIINFO
Indicator ave x:103 y:-7 z:-1017 roll:170 pitch:554 HV:Grip Up
Indicator ave x:102 y:-5 z:-1016 roll:172 pitch:554 HV:Grip Up
Indicator ave x:102 y:-5 z:-1018 roll:172 pitch:554 HV:Grip Up
Indicator ave x:101 y:-6 z:-1017 roll:171 pitch:554 HV:Grip Up
Indicator ave x:102 y:-6 z:-1016 roll:171 pitch:554 HV:Grip Up
Indicator ave x:101 y:-6 z:-1014 roll:171 pitch:554 HV:Grip Up


Does start a periodic logging of the cameras gyroscope. Moving the camera does change the values.