Hi !
A few days ago, I started a topic on the CHDK forum, about DIGIC 5 JTAG on a Canon S100 : https://chdk.setepontos.com/index.php?topic=13408.0
So far, I'm able to connect to the ARM, but I can't do more than peeking registers values. The camera immediately freezes, and eventually turns off.
Does anyone here has some experience with JTAG on DIGIC chips ?
Very cool.
No experience with JTAG, but there might be a watchdog somewhere. If you lock up the CPU on a PowerShot model, by executing something like "cli(); while(1);" from some CHDK task, I remember the camera reboots (but no PowerShot currently here to double-check). That's different from EOS - there, it locks up and the MPU throws ERR80 shortly afterwards (as the main CPU is no longer responding). There's no MPU on PowerShots (there may be other secondary CPUs though).
good job.
never was that brave to try this on a 5D3 :)
or does anyone sponsor a mechanically defect one where i can solder on? :D
peeking registers and memory is definitely a helpful feature.
i am using a professional debugger (lauterbach TRACE32) at work.
on such a complex system, memory insight is very valuable.
You know if you really want one we can make it happen. Easily, I'm convinced.
nevermind, i think on the 5D3 i didnt even find a matching connector.
the 600D instead had an unpopulated one, which i guessed to be JTAG
Somebody once told me that the JTAG connector was accessible through the grip connector...
possible, but i expected it to be closer to the PCB. hmm.
Effectively, that shutdown seems to be related to a watchdog timer. By analyzing Canon's watchdog functions, it seems that the only addressed used for interfacing with the watchdog is 0xC0410000.
The first line of code is equivalent to this :
*(0xC0410000) = 0;So I thought this might disable the watchdog. In order to try this, I used chdkptp and used the EngDrvOut function :
Quote=call_func_ptr(0xFF025C0C, 0xC0410000, 0, 0)
It seems that this solves the issue of the camera shutting down a few seconds after entering JTAG. However the camera remains non-responsive to physical buttons or USB communication :-\
guess thats due to the MPU getting out of sync and shutting down
Quote
target halted in ARM state due to debug-request, current mode: Abort
That sounds like it stopped other DryOS tasks and waits for debugger commands, which may explain why it appears locked up. Just a guess.
Quote from: g3gg0 on April 28, 2018, 04:45:34 PM
guess thats due to the MPU getting out of sync and shutting down
There's no MPU on PowerShot cameras; there, button presses are handled by a background task on the ARM side (PhySw) that polls some hardware registers that encode button status (usually each button mapped to one bit).
Example from my experiments with A2200:
.physw_regs = { 0xC0220200, 0xC0220204, 0xC0220208 },
.physw_idle_state = { 0x4690C0C4, 0x04eff443, 0x00000000 },
KeyMap keymap[] = {
/* tiny bug: key order matters. see kbd_get_pressed_key() */
{ 0, CHDK_KEY_PLAYBACK ,0x01000000 }, // Found @0xffb561dc, levent 0x601
{ 0, CHDK_KEY_MENU ,0x04000000 }, // Found @0xffb561e4 (1.00B), levent 0x09
{ 0, CHDK_KEY_FACE ,0x00800000 },
{ 1, CHDK_KEY_UP ,0x00001000 }, // Found @0xffb56214 (1.00B), levent 0x04
{ 1, CHDK_KEY_RIGHT ,0x00002000 }, // Found @0xffb5621c (1.00B), levent 0x07
{ 1, CHDK_KEY_DOWN ,0x00004000 }, // Found @0xffb56224 (1.00B), levent 0x05
{ 1, CHDK_KEY_LEFT ,0x00008000 }, // Found @0xffb5622c (1.00B), levent 0x06
{ 1, CHDK_KEY_ZOOM_OUT ,0x00010000 }, // Found @0xffb56234 (1.00B), levent 0x03
{ 1, CHDK_KEY_ZOOM_IN ,0x00020000 }, // Found @0xffb5623c (1.00B), levent 0x02
{ 1, CHDK_KEY_SET ,0x00040000 }, // Found @0xffb56244 (1.00B), levent 0x08
{ 1, CHDK_KEY_DISPLAY ,0x00080000 }, // Found @0xffb5624c (1.00B), levent 0x0a
{ 1, CHDK_KEY_SHOOT_FULL ,0x00000003 }, // Found @0xffb5620c (1.00B), levent 0x01
{ 1, CHDK_KEY_SHOOT_FULL_ONLY ,0x00000002 }, // Found @0xffb5620c (1.00B), levent 0x01
{ 1, CHDK_KEY_SHOOT_HALF ,0x00000001 }, // Found @0xffb56204 (1.00B), levent 0x00
{ 0, CHDK_KEY_POWER ,0x02000000 }, // Found @0xffb561e4 (1.00D), levent 0x600
{ 0, 0, 0 }
};
Quote from: a1ex on April 28, 2018, 04:54:53 PM
That sounds like it stopped other DryOS tasks and waits for debugger commands, which may explain why it appears locked up. Just a guess.
depends how the "break" command is implemented. being in ABORT (see PC, which says DATA ABORT) is either due to accessing forbidden areas after breaking, or hmm it inserted that ABORT to stop the execution.
(not sure how the OpenOCD issues memory read commands)
i know i shouldn't be bumping old threads but any ideas where to begin for DIGIC7 chips?