Suggestions are always welcome, I'd appreciate it.I am not a programmer and do not fully understand all precesses.All I know about the firmware and modifications of the same I've learned by reading this forum and advice of people who know much more than me. One can say that I understand C code, assembler is much larger problem. I understand some basic things about the work of ASM code, but a deeper analysis and tracking within the ASM code is a problem.
' RAM dumperdim f,a,startadr=0,romsize=0x1000000,msgstr=0private sub mydump(c, d) sprintf(msgstr,"A/%0X.BIN",c) LCDMsg_SetStr(a,msgstr) f=Fopen_Fut(msgstr,"w") Fwrite_Fut(c,d,1,f) Fclose_Fut(f)end subprivate sub Initialize() UI.CreatePublic() a=LCDMsg_Create() LCDMsg_SetStr(a,"Running") System.Create() if ExecuteEventProcedure("UI_RegistDebugEventProc") = -1 then ExecuteEventProcedure("UI.CreatePublic") end if msgstr = AllocateMemory(80) mydump(0,0x1000000) LCDMsg_SetStr(a,"Done") FreeMemory(msgstr)end sub
In case you know how to run Canon Basic scripts, here's a RAM dumper script that will dump the first 16MB.
Here is a RAM dump.
The SD card related flag is 2 (it's a byte at 0x3618).The startup flag (word at 0x2cf4 + 8 = 0x2cfc) is 0x400000. That means 0x400000 is playback mode, my guess for booting in rec mode is still 0x200000 (from sub_ff073c68).
Yes, I see now.Code for normal start is :*(int*)(0x2cf4+0x8) = (*(int*)0xc022f48c) & 0x80000 ? 0x400000 : 0x200000;short press - play mode, long press - rec mode.Start in the play mode with a short press leads to an error on the memory card.Start in the rec mode with a long press works well with all cards. There is no memory card error.
Would be interesting to see if these 2 variables remain the same when using a card that behaves differently in diskboot. Can you make another dump and tell which dump was made on a 'good' and which on a 'bad' card?
You could experiment with combining (AKA ORing/adding) one of the remaining flags with 0x400000 for playback mode. These are: 0x40000, 0x800000, 0x100000. Per your earlier observations, 0x100000 might be related to that separate operating mode. You could also try combining 0x400000 and 0x200000 and see what happens.But I'm guessing that the playback and ON/OFF buttons might be also sampled somewhere else in the boot process, in which case the above advice won't be effective.
Here is RAM dump from "bad" card,if it is still important.(...)RAM dump in reply#82 is from "good" card.
Interesting. Can you take some more samples (512kB size is enough in this case) of the good and bad card? Wait a few seconds before starting the dumper.
good:https://drive.google.com/open?id=0B2NRqqO9AOURRUFINnBxWTkxUEkbad:https://drive.google.com/open?id=0B2NRqqO9AOURblVOalZnSmpQVXcOne more set.bad:https://drive.google.com/open?id=0B2NRqqO9AOURczNPQkRUWGlVMzggood:https://drive.google.com/open?id=0B2NRqqO9AOURQ3d6OUtlWG1VSkU
It's possible of course that the firmware needs some time to fill them or that the cards' speed is much different, so this might very well be a false lead.
Started by gvandyk CHDK Releases
Started by Jez General Help and Assistance on using CHDK stable releases
Started by ProfHankD « 1 2 » Feature Requests
Started by eaglesong General Chat
Started by duenyas General Discussion and Assistance
