DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

[names_are_hard]

Found a nice missing piece, I had incorrect DRYOS_ASSERT_HANDLER in consts.h, so I wasn't generating CRASH00.LOG.

[nikfreak]

Nice one. Now you just may also use several lines of bmp_printf (e.g test1, test2, test3, test4...) to write some text onto the screen and use this approch to locate code which causes trouble. Afterwards it's easy to see which stubs / consts are used around / within that code. You then either uncomment that code and see where code execution reaches (next bmp_printf) or better fix the stubs / consts first. I used this approach a lot and even still do in vb6 when i get stuck in one of my private projects

Next, enable features one by one and use same approach...

[names_are_hard]

debug printfs - shameful, but we all use them (entirely excusable here, where you don't have a debugger!).  I've added a convenience printf that works like this:
bmp_printf_auto("some string with data: %d", 6")
It has static x and y which it increments for you.  Nice for lazily printing things in order.

The fixed assert handler has made it much more stable.  Lockups are rare.

This is probably too hopeful, but I wonder if the main thing stopping me getting into ML menus is I haven't defined the button to trigger it?  I think this is supposed to be the delete / bin / trash button, but I don't know where to find it in consts / stubs / code.  What's the name used?  Or, more generallly, what's the path that leads to ML menus, so I can debug it?

[MrDerrick]

Hi, i have an 800d, I can help you in any way?

[names_are_hard]

Digic7 are in very early stages.  Do you have experience with C or disassembly, or have the time to learn?

[nikfreak]

This is probably too hopeful, but I wonder if the main thing stopping me getting into ML menus is I haven't defined the button to trigger it?  I think this is supposed to be the delete / bin / trash button, but I don't know where to find it in consts / stubs / code.  What's the name used?  Or, more generallly, what's the path that leads to ML menus, so I can debug it?

Check platform dir and gui.h in it.
Might be a good idea to copy and use that from my 100d port. You can also grep source code for 100D

[names_are_hard]

Ah, I'd forgotten about gui.h, thank you.  I took a look at it, and I can see it's associated with button codes in gui_massive_event_loop, but comparing between 50D and 200D is difficult.  I think Ghidra has decompiled them in different ways, one part that I'd expect to be a switch is a messy if/else nest.  I think I will have to come back to this part.

Other problems I have: this crash log:

ASSERT: 0
at TouchUtility.c:132, task DispDCtrl
lv:0 mode:0

DispDCtrl stack: 28d100 [28d218-28c218]
0xUNKNOWN  @ 1b67db:28d100

Which I think is related to these debug messages:

19.697151   DispVCtrl:e054852d:42:02: GiveSemaphore : StateChangeWaitCBR 56
19.697188   DispDCtrl:e04e2e51:45:03: TCH_ProhibitTouch
19.697216   DispDCtrl:e055a3bb:45:03: JDI_LAM_ProhibitTouch
19.697245   DispDCtrl:e059bec3:45:06: TryPost Cannot be Done!!! 3   <--- I think this is strongly related to the assert

I can locate the function that triggers those messages but it's not obvious how I fix the crash.  I also don't know if I need to - the camera remains responsive.  Perhaps this is not a high priority?  Anyone know a general pattern for dealing with these kinds of logs?  To debug this further I think I would write a dynamic patching util to dump register contents and stacktrace when a given address was hit, which would be fun but likely slow to get working reliably (if it was x86 asm it would be easy ).

I also find that any attempt to vsnprintf() with %s in the format string has a high chance of causing a very fast crash, fast enough that it stops the string being displayed.  But, it's not a guarantee, just very likely.  Sometimes you get part of the string displayed before locking up.  I don't understand this fully and can't explain it.  It evens occurs with local static strings as the arg.  There is nothing in crash logs when this happens.  I'm mostly mentioning this in case it confuses other Digic7 porters, but if this makes sense to anybody, please let me know.

[nikfreak]

I would just try to disable touch in canon menu until you find the root cause (stub / const). It's at least possible on 100d. Do you have a pull request available? It might help others to chime in

[kitor]

Do you have a pull request available? It might help others to chime in

https://bitbucket.org/stephen-e/ml_200d/
I don't think that this will be ready for PR anytime soon 

[names_are_hard]

Disabling touch in the menus was a good idea I hadn't thought of, thanks.  It didn't help, still get the same crash.  I note that the debug messages look related to disabling touch, and the camera will crash if I halfshutter - perhaps it always tries to disable the touchscreen when the display is off?  It does give me the crash log if I insert card, turn on cam, do nothing, turn off cam - but that leads to a display off too.  It's a pattern worth investigating.

I'm happy to look at PRs, but they'd be Git ones, not HG.  Unless Kitor was simply saying my code is too painful to work with   I'll also throw stuff over the fence into HG land if people want me to (but I don't want to use it all the time).

[kitor]

I thought about PR into unified which this is based on
Obviously taking this as a new branch in ML repo is different story - and may encourage others to give it a try.

I really need to find some time and dig for stubs on R to try this. I hope for next month - depends mostly on how long will take me to migrate all stuff from server running in my closet to full-blown rack setup in my parents house ("just IT things") 
You know that you work on too many items at once when you have multiple kanban boards just for your own projects...
/ot

[names_are_hard]

A quick update: I am not dead, was just too busy with other stuff (including Blackhat / DEFCON, which was pretty cool).

I am feeling kind of stuck though, I don't know how to proceed with the assert from a few messages back.  If anyone could help diagnose or suggest changes / tests, please do.  Best guess I've come up with is blanking the back screen triggers Canon to disable the touchscreen, and disabling the touchscreen triggers a crash (but why?).  I haven't thought of an easy test for this theory.

For now I am doing a second pass over all the stubs I've found, and sorting them into high / middling / low confidence findings.  If anyone would like to help there, you could do that without running code.  In particular, looking at low confidence stubs and either finding better choices, or explaining why I'm right on the one I've found, so confidence is improved:
https://bitbucket.org/stephen-e/ml_200d/src/dev/platform/200D.101/stubs.S