S100 porting thread - page 26 - DryOS Development - CHDK Forum supplierdeeply

S100 porting thread

  • 286 Replies
  • 97170 Views
Re: S100 porting thread
« Reply #250 on: 15 / July / 2014, 10:35:00 »
Advertisements
Quote
SDM uses exactly the same code for wait for the remote release.  Does it exhibit the same crash?
yes
What happened when you tried it ? 
I have never compiled CHDK.
Cute.  So I'll be more explicit.  What happened when you tried to fix this in SDM?

Hmmm .... a quick Forum search that I have just done shows that this was known two years ago :-
Quote
As Werner suggests, continually forcing to zero while switch is pressed should disable it.
Before anyone spends any time on this, it would be nice to know what else you have already attempted and what other tidbits you've discovered in your forum searches?
Ported :   A1200    SD940   G10    Powershot N    G16

Re: S100 porting thread
« Reply #251 on: 15 / July / 2014, 10:41:31 »
Quote
What happened when you tried to fix this in SDM? .

I have not tried to fix this in SDM.

It is a beautiful day, time for some photography.........

*

Offline srsa_4c

  • ******
  • 4426
Re: S100 porting thread
« Reply #252 on: 15 / July / 2014, 17:18:33 »
Here's what can be worked out from the romlog (used the 100d firmware here):

assert happens here due to the failure of TryPostMessageQueue (assumption: the queue became full):
Code: [Select]
loc_ff0ec028: ; 7 refs
ff0ec028: push {r3, r4, r5, r6, r7, lr}
ff0ec02c: ldr r5, =0x5ff4
ff0ec030: mov r6, #0
ff0ec034: mov r4, r0
ff0ec038: str r6, [sp]
ff0ec03c: ldr r0, [r5, #116] ; 0x74
ff0ec040: mov r1, sp
ff0ec044: bl loc_ff02b098 ; <TryReceiveMessageQueue>
ff0ec048: ldr r1, [sp]
ff0ec04c: orr r0, r0, r1
ff0ec050: tst r0, #1
ff0ec054: ldm r4, {r0, r2}
ff0ec058: movne r1, r6
ff0ec05c: stm r1, {r0, r2}
ff0ec060: ldr r0, [r5, #72] ; 0x48
ff0ec064: bl loc_ff02b1d4 ; <TryPostMessageQueue> @ 0x5ff4 + 0x48
ff0ec068: cmp r0, #0
ff0ec06c: beq loc_ff0ec07c
ff0ec070: ldr r1, =0x10f ; 271
ff0ec074: add r0, pc, #524 ; *"ChaseFrame.c"
ff0ec078: bl loc_ff00edc8 ; <DebugAssert>
loc_ff0ec07c:
ff0ec07c: pop {r3, r4, r5, r6, r7, pc}
the message queue is read by this task:
Code: [Select]
NSTUB(task_ChaseFrame, 0xff0ec080):
ff0ec080: push {r3, r4, r5, r6, r7, lr}
ff0ec084: ldr r4, =0x5ff4
ff0ec088: ldr r6, =0x131
ff0ec08c: add r5, r4, #152 ; 0x98
loc_ff0ec090:
ff0ec090: ldr r0, [r4, #72] ; 0x48
ff0ec094: mov r2, #0
ff0ec098: mov r1, sp
ff0ec09c: bl loc_ff02afd0 ; <ReceiveMessageQueue> @ 0x5ff4 + 0x48
...
this routine tried to send the message:
Code: [Select]
loc_ff0ec17c:
ff0ec17c: push {r2, r3, r4, lr}
...
ff0ec22c: bl loc_ff0ec028
loc_ff0ec230:
ff0ec230: pop {r2, r3, r4, pc}
loc_ff0ec17c is registered as a function pointer by loc_ff16a660
Code: [Select]
ff0ecc24: add r0, pc, #500 ; *"ChaseFrame"
ff0ecc28: bl loc_ff02b808 ; <CreateTaskStrictly>
ff0ecc2c: ldr r0, =0xff0ec17c
ff0ecc30: bl loc_ff16a660
...

loc_ff16a660:
ff16a660: ldr r1, =0x7a94
ff16a664: str r0, [r1]
ff16a668: bx lr
the function pointer is called by this task:
Code: [Select]
NSTUB(task_MotionVector, 0xff169de8):
ff169de8: push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
ff169dec: ldr r9, =0x7a94
...
ff16a0e4: ldr r1, [r9]
ff16a0e8: cmp r1, #0 ; can be NULL !
ff16a0ec: beq loc_ff16a118
ff16a0f0: ldr r0, [r9, #36]
ff16a0f4: str r0, [sp, #228]
ff16a0f8: ldr r0, [sp, #500]
ff16a0fc: str r0, [sp, #224]
ff16a100: ldr r0, [r9, #40]
ff16a104: str r0, [sp, #236]
ff16a108: ldr r0, [sp, #496]
ff16a10c: str r0, [sp, #232]
ff16a110: add r0, sp, #224
ff16a114: blx r1
...
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0. I have no idea what the consequences of this can be, it will likely still crash, but somewhere else.

I haven't been able to reproduce the issue on my cameras (tried 3 of them).

Re: S100 porting thread
« Reply #253 on: 15 / July / 2014, 17:32:46 »
.
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0.

Well ....................  as I have never compiled CHDK builds I will try on an SDM build.

For quite some time the double-click method has been disabled for the S100 because a user reported this problem.

The parameters override code (on half press) is only entered once so even if you zero at the start of half press it will probably be quickly set again by the system.

While waiting for switch release you could continually zero the value, if that is not too late.

« Last Edit: 15 / July / 2014, 17:39:24 by Microfunguy »


Re: S100 porting thread
« Reply #254 on: 16 / July / 2014, 00:28:15 »
Quote
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0.
yes this fixes the problem with face detection

Werner

Re: S100 porting thread
« Reply #255 on: 16 / July / 2014, 05:07:40 »
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0. I have no idea what the consequences of this can be, it will likely still crash, but somewhere else.

Thanks to the always-helpful, friendly and knowledgeable srsa_4c that solves the problem :)

In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.

Some general questions for srsa_4C  .................

Do you use IDA ?
If so, your disassembly is different to mine.
Also, do you have to manually force disassembly to code of many sections ?

Where are NSTUB(task_MotionVector, 0xff169de8) and NSTUB(task_ChaseFrame, 0xff0ec080) defined ?

Quote
loc_ff0ec17c is registered as a function pointer by loc_ff16a660

loc_ff16a660:
ff16a660:   ldr   r1, =0x7a94
ff16a664:   str   r0, [r1]
ff16a668:   bx   lr

Can you explain what is meant by that ?



*

Offline srsa_4c

  • ******
  • 4426
Re: S100 porting thread
« Reply #256 on: 16 / July / 2014, 18:13:04 »
In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.
Actually, I think that the firmware only sets 0x7a94 once, not continuously. What I would do is to save its original value before the critical operation and restore it afterwards. (I could be wrong of course.)

Quote
Do you use IDA ?
If so, your disassembly is different to mine.
No, the excerpts are from a "GPL" disassembly, hand-edited a bit. Objdump blindly disassembles everything, no need to force it.

Quote
Where are NSTUB(task_MotionVector, 0xff169de8) and NSTUB(task_ChaseFrame, 0xff0ec080) defined ?
See the funcs_by_*.csv files under /platform/<cam>/sub/<...>/
Quote
Quote
loc_ff0ec17c is registered as a function pointer by loc_ff16a660

loc_ff16a660:
ff16a660:   ldr   r1, =0x7a94
ff16a664:   str   r0, [r1]
ff16a668:   bx   lr

Can you explain what is meant by that ?
The firmware variable at 0x7a94 is a function pointer. loc_ff16a660 is a simple function that takes a function pointer and sets that variable.

Re: S100 porting thread
« Reply #257 on: 16 / July / 2014, 19:35:34 »
Do you use IDA ?
I don't use IDA either but you seem to be struggling with it.

So if you are trying to use the Canon signature file and/or debug scripts for CHDK mentioned here :
        http://chdk.wikia.com/wiki/Loading_dump_to_IDA
then you probably want to take a look at how they are setup.  The profile is for an old A-series camera and the debug scripts  (CHDK.IDC etc)  have all kinds of hard coded addresses (look for things like ROM_START  & sb = 0xFF000000;) built in that will not match the ROM size of more recent cameras.   In addition,  many recent cameras relocate part of the code in ROM to RAM, which is also not handled automatically by the CHDK debug scripts.
« Last Edit: 16 / July / 2014, 20:32:37 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline nafraf

  • *****
  • 1308
Re: S100 porting thread
« Reply #258 on: 17 / July / 2014, 01:24:19 »
In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.
Perhaps wait_until_remote_button_is_released is called too early. Here is a test version for 100d.
« Last Edit: 08 / September / 2014, 11:54:16 by nafraf »

Re: S100 porting thread
« Reply #259 on: 17 / July / 2014, 03:34:56 »
Quote
Here is a test version for 100d.
I could do the test if you could compile and upload the 101b version

Werner

 

Related Topics