Crash motionvector with long running script (split from A3300 porting) - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2] 3   Go Down

Crash motionvector with long running script (split from A3300 porting)

  • 23 Replies
  • 11560 Views
*

Offline reyalp

  • ******
  • 14111
Re: Re: port for A3300IS / what reference port to use?
« Reply #10 on: 24 / August / 2015, 23:02:54 »
Advertisements
Quote from: davedude on 24 / August / 2015, 21:55:15
This camera is running ixus115_elph100hs-100c-1.3.0-4169

Same settings (no servo, no blink, AF frame center...)

Last photo taken: 2015:08:23 06:22:04

Romlog:

ASSERT!! MotionVector.c Line 339
Occured Time  2015:08:23 06:22:12
Task ID: 24379444
Task name: LiveImageTas0
Thanks. Very interesting that it's the exact same assert.

The firmware code in question (around FF9309E4 on ixu115_elph100hs 100c) looks like
Code: [Select]
BL      TryReceiveMessageQueue
TST     R0, #1
LDRNE   R1, =0x153
ADRNE   R0, aMotionvector_c ; "MotionVector.c"
BLNE    DebugAssert
This is deep in a task we don't directly do anything with, so it's a bit of a puzzle.

You mentioned earlier
Quote
The romlog I posted was using a slight modification to that script (it shuts the display off immediately after each shot.)
Manipulating the display could plausibly have a role in confusing the Canon "MotionVector" code, so trying without is a reasonable idea.
Logged
Don't forget what the H stands for.
*

Offline davedude

  • *
  • 12
Re: Re: port for A3300IS / what reference port to use?
« Reply #11 on: 25 / August / 2015, 13:18:23 »
A3300 crashed using standard selective intervalometer script.

Last photo again 9 seconds before the crash at  2015:08:25 10:04:34


ASSERT!! MotionVector.c Line 339
Occured Time  2015:08:25 10:04:43
Task ID: 23330866
Task name: LiveImageTas0
SP: 0x0031B1D0
StackDump:
0x00000000
0xFF91AE98
0x00000153
0x000A10B4
0x000020D0
0x00005854
0x00002710
0x00000000
0x00000004
0x40546B80
0x19980218
0xFF91B118
0x00000003
0x0031B268
0x000020D0
0x00000000
0x0000229C
0x00000003
0x00000004
0xFF8526DC
0x0000083B
0x0009ED40
0x00004FC4
0x00105003
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0xFF8FA4C8
0x00000004
0x00000001
0x02000000
0x0000000A
0x19980218
0xFFB7A474
0x00000168
0x000000F0
0x000002D0
0x000000F0
0x0009ED40
0x00000000
0x00005068
0xFF8FDA14
0x00000004
0x00005068
0x00000000
0x19980218
0x19980218
0xFF8FDB7C
0x0009EB38
0x002F30A4
0x19980218
0xFF816B78
0x19980218
0x19980218
0x00001008
ShootConDump:
80 00 0f 02 2f 80 00 0f 04 3f 00 00 0f 00 0f 20
00 0f 00 0f 60 00 0f 00 0f 70 00 0f 00 0f 80
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
52800450: UI:MuteOffPhysicalScreen
52800450: UI:ScreenLock
52800450: UI:ScreenUnLock
52800460: UI:ShtCon_StartReview
52800460: UI:_EntryActionReview
52800460: SS:StartRev
52800460: UI:ScreenLock
52800460: UI:ScreenUnLock
52800460: UI:LogicalEvent:0x311f:adr:0,Para:0
52800460: UI:ShootState:0x81
52800460: UI:DisplayPhysicalScreenCBR
52800460: UI:ShootState:0x82
52800460: SS:IsQ=1
52800460: SS:ExitShoot
52800470: UI:ShootState:0x72
52800470: UI:DisplayPhysicalScreenCBR
52800600: UI:DSIC:47,0
52800610: UI:ShootSeqToUI:0x2007:adr:0xf4e,Para:3918
52800610: UI:ShootSeqToUI:0x2001:adr:0,Para:0
52800610: UI:DSIC:46,0
52800620: UI:ShootSeqToUI:0x201e:adr:0xf4e,Para:3918
52800620: UI:ShootSeqToUI:0x2029:adr:0xf4e,Para:3918
52800620: UI:ShtCon_EnableReviewHold:IsPressSwTwo:0
52800620: UI:ShtCon_EnableReviewHold:IsAvailableShots:1
52800620: UI:DSIC:4c,0
52800620: SS:StopRev
52800630: UI:ScreenLock
52800650: UI:PB.RefPB
52800670: UI:PB.DrawI
52800670: UI:ShtCon_EnableReviewHold:IsPressSwTwo:0
52800670: UI:ShtCon_EnableReviewHold:IsAvailableShots:1
52800670: SS:NextAvail(7),ReviewAvail(5)
52800830: UI:DSIC:48,0
52801010: UI:LogicalEvent:0x3204:adr:0,Para:0
52801020: UI:PB.DcdCBR
52801020: UI:PB.RfrsI
52801030: UI:DispSwCon_MuteOffPhysicalScreen
52801030: UI:Window Reduce MuteOff
52801030: UI:ScreenUnLock
52801030: UI:Window Re MuteOff
52801030: UI:MuteOffPhysicalScreen
52801040: UI:DisplayPhysicalScreenCBR
52802680: UI:LogicalEvent:0x311e:adr:0,Para:0
52802680: UI:ShtCon_StopReview
52802680: UI:StopRecReviewController
52802680: UI:PB.StopR
52802680: UI:ScreenLock
52802690: UI:ScreenUnLock
52802690: UI:LogicalEvent:0x3120:adr:0,Para:0
52802690: UI:ShootState:0x83
52802690: UI:ShootState:0x74
52802690: UI:ShtAutoShutterLib_IsActivateSmileShutter:0
52802690: UI:ShootState:0x80
52802690: UI:ShootState:0x70
52802690: UI:ShtCon_ExitSequenceState
52802690: UI:_ExitSequenceWithoutSw1Check
52802690: UI:_ExitActionReview
52802700: SS:CancelPre
52803400: SS:ChargeComplete
52803400: UI:DispSwCon_MuteOffPhysicalScreen
52803400: UI:Window MuteOff
52803400: UI:MuteOffPhysicalScreen
52803400: UI:ShtCon_Deactivate
52803400: UI:DSIC:14,0
52803400: UI:DSIC:60,0
52803400: UI:DispSwCon_TurnOnDisplayDevice
52803400: UI:ScreenLock
52803520: UI:DispSw: Unlock
52803520: UI:DispSwCon:Unlock
52803520: SS:IsQ=1
52803520: UI:TerminateDeliverToZoomController
52803620: UI:OPTICAL_ZOOM_POS
52803620: UI:UnpressZoomLever
52803620: SS:IsQ=1
52803630: UI:ShtCon_EntryIdleShoot
52803630: UI:ShootState:0x0
52803630: UI:DisplayPhysicalScreenCBR
52803630: UI:ScreenUnLock
52803640: UI:DisplayPhysicalScreenCBR
52807120: UI:ScreenLock
52807130: UI:ScreenUnLock
 

Logged
*

Offline reyalp

  • ******
  • 14111
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #12 on: 25 / August / 2015, 16:14:48 »
Thanks. I've split and renamed the topic since it seems clear this isn't a A3300 issue (not your fault, it was the right place to post with the info you had at the start.)

FYI, you can attach the romlogs using the attachment option when posting.

One thing to try would be running a different intervalometer script.
Logged
Don't forget what the H stands for.
*

Offline davedude

  • *
  • 12
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #13 on: 26 / August / 2015, 10:16:17 »
A3300, my script, last photo at 2015:08:06 07:05:10, crash at ...:18

I don't think the 8-9 seconds after last photo can be considered coincidental at this point.

Logged
*

Offline reyalp

  • ******
  • 14111
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #14 on: 26 / August / 2015, 16:37:38 »
Quote from: davedude on 26 / August / 2015, 10:16:17
A3300, my script, last photo at 2015:08:06 07:05:10, crash at ...:18

I don't think the 8-9 seconds after last photo can be considered coincidental at this point.
Yeah, that's looking like a pattern.

If you can come up with a minimal script that reproduces the problem relatively quickly, that would be helpful. Maybe shooting every 15 seconds or so?
Logged
Don't forget what the H stands for.
*

Offline davedude

  • *
  • 12
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #15 on: 01 / September / 2015, 00:59:36 »
Documenting all the settings on my A3300 in case someone wants to recreate this crash in the future.  Standard "Selective Intervalometer" script linked earlier in this thread.  "Default" means I did not change anything from what came up by default with the distribution I posted earlier.

I've moved on to trying workarounds. Right now I have the camera sleeping through the 8-9 second after shutter release "crash zone" (I put it to sleep for 30 seconds after the picture has been taken as I am taking pictures once a minute.)  Ran all day today, but I'll post back in a few days with a more definitive result.



Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #16 on: 01 / September / 2015, 18:02:58 »
Quote from: davedude on 01 / September / 2015, 00:59:36
the 8-9 second after shutter release "crash zone"
If you observe the camera (and its LCD) while the script is working, does anything visible happen 8-9 second after the shot?
Logged
*

Offline davedude

  • *
  • 12
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #17 on: 01 / September / 2015, 19:56:30 »
Quote from: srsa_4c on 01 / September / 2015, 18:02:58
If you observe the camera (and its LCD) while the script is working, does anything visible happen 8-9 second after the shot?

Nothing going on.  In the standard script, the cam is showing the viewfinder as if it were ready to take a picture.  In my version, the display is off.

The script will be in this loop during the crash:
:wait_loop
    b=get_tick_count
    if b<S then goto "wait_loop"

The canon software must be doing some housekeeping occasionally, and we're out of memory or stack, or changed something that conflicts.
Logged
*

Offline davedude

  • *
  • 12
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #18 on: 01 / September / 2015, 20:02:25 »
I left my elph 100 HS running over the weekend and it crashed again.  Last pic at 2015:30:8 12:56:53, crash at 2015:08:30 12:57:01.    8 Seconds later, again.  Log attached.

This cam is less sensitive to this issue, it runs several days before it shows up.  Something different in the resource requirements for CHDK or Canon software that makes the glitch less frequent.

I'm switching this cam to the sleep script as well to see how it holds up. 
Logged
*

Offline reyalp

  • ******
  • 14111
Re: Crash motionvector with long running script (split from A3300 porting)
« Reply #19 on: 01 / September / 2015, 21:45:10 »
Quote from: davedude on 01 / September / 2015, 19:56:30
The script will be in this loop during the crash:
:wait_loop
    b=get_tick_count
    if b<S then goto "wait_loop"
If I were doing this, I would just calculate the time to S and sleep for that time. However, ubasic should sleep every line, so I don't think this should cause any CPU starvation unless set_yield has been used, which doesn't appear to be the case for this script.

(The script has some comments about not using sleep giving more accurate timing, but I don't agree)

Hmm, the ubasic goto statement does scan the script from the start looking for the label, without yielding, so I guess it's a little CPU intensive.

Quote
The canon software must be doing some housekeeping occasionally, and we're out of memory or stack, or changed something that conflicts.
Memory should be OK unless there's a leak, ubasic doesn't take take much. In Lua you can query free memory, but this isn't available in ubasic. In any case, the assert doesn't appear to be directly out-of-memory related.

As for stack, the script runs in kbd_task and should have plenty for simple ubasic. The motionvector stuff runs in it's own task with it's own stack that we don't touch. Stack overflow in one task can cause weird problems, but IMO it's extremely unlikely it would show identical failure on two different cameras.

Tying up the CPU for too long could be plausible, but I'd be surprised if this was happening.

It's a puzzle :blink:

edit:
If it is caused by CHDK hogging the CPU, you might be able to make it happen sooner by putting something like set_yield 10000 500 at the start of the script.
« Last Edit: 01 / September / 2015, 22:27:03 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal