S100 porting thread - page 26 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 ... 21 22 23 24 25 [26] 27 28 29   Go Down

S100 porting thread

  • 286 Replies
  • 130595 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: S100 porting thread
« Reply #250 on: 15 / July / 2014, 10:35:00 »
Advertisements
Quote from: wbloos on 15 / July / 2014, 02:59:33
Quote
SDM uses exactly the same code for wait for the remote release.  Does it exhibit the same crash?
yes
Quote from: Microfunguy on 14 / July / 2014, 20:06:45
Quote from: waterwingz on 14 / July / 2014, 19:53:07
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?

Quote from: Microfunguy on 15 / July / 2014, 05:16:43
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?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
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.........
Logged
*

Offline srsa_4c

  • ******
  • 4451
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 lrthe 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).
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: S100 porting thread
« Reply #253 on: 15 / July / 2014, 17:32:46 »
Quote from: srsa_4c on 15 / July / 2014, 17:18:33
.
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 »
Logged
*

Offline wbloos

  • *
  • 25
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
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: S100 porting thread
« Reply #255 on: 16 / July / 2014, 05:07:40 »
Quote from: srsa_4c on 15 / July / 2014, 17:18:33
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 ?


Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: S100 porting thread
« Reply #256 on: 16 / July / 2014, 18:13:04 »
Quote from: Microfunguy on 16 / July / 2014, 05:07:40
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.
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: S100 porting thread
« Reply #257 on: 16 / July / 2014, 19:35:34 »
Quote from: Microfunguy on 16 / July / 2014, 05:07:40
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 »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline nafraf

  • *****
  • 1308
Re: S100 porting thread
« Reply #258 on: 17 / July / 2014, 01:24:19 »
Quote from: Microfunguy on 16 / July / 2014, 05:07:40
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 »
Logged
*

Offline wbloos

  • *
  • 25
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
Logged
Pages: 1 ... 21 22 23 24 25 [26] 27 28 29   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal