A1400 porting thread - page 7 - DryOS Development - CHDK Forum

A1400 porting thread

  • 130 Replies
  • 33833 Views
*

Offline timgor

  • ***
  • 150
Another issue about A1400
« Reply #60 on: 15 / February / 2014, 11:40:03 »
Advertisements
I tested another script and my camera crashes occasionally.
I'm not sure that this bug related to the A1400 only.
Can you lease look at the ROMLOG?
« Last Edit: 15 / February / 2014, 11:42:49 by timgor »

*

Offline reyalp

  • ******
  • 13667
Re: Another issue about A1400
« Reply #61 on: 15 / February / 2014, 17:19:26 »
I tested another script and my camera crashes occasionally.
I'm not sure that this bug related to the A1400 only.
Can you lease look at the ROMLOG?
It would be helpful if you could tell us *which* script(s) and what was happening when the crash occurred.

The crash is in
Quote
ASSERT!! ReadFDir.c Line 443
Occured Time  2014:02:15 01:56:16
Task ID: 13238302
Task name: PhySw
Given that it's in physw task, it's probably in a call from CHDK code. The same assert was previously seen in http://chdk.setepontos.com/index.php?topic=8613.msg91292#msg91292 where it appears to have been due to low free memory.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13667
Re: A1400 porting thread
« Reply #62 on: 16 / February / 2014, 23:06:53 »
I confirmed that the above assert is triggered when AllocateUncacheableMemory fails.

Here's a test build with ARAM enabled, which should help a bit.

It would be helpful if you can report the "Miscellaneous"->"free memory" number for the build you were using and this one.
Don't forget what the H stands for.

*

Offline timgor

  • ***
  • 150
Re: A1400 porting thread
« Reply #63 on: 19 / February / 2014, 11:01:53 »
Yes it was memory issue. I just cleaned with collectgarbage("collect") and it gone.
I use default motion detector script with continuous shot during 5 seconds. There is another romlog file that I got after about 8 hours of work. What can it be? I couldn't find it in this forum.

Does the compiled program  a1400-100b-1.3.0-3359-full-aram-test-1.zip have a different solution to prevent memory crash?
« Last Edit: 19 / February / 2014, 11:10:43 by timgor »


*

Offline reyalp

  • ******
  • 13667
Re: A1400 porting thread
« Reply #64 on: 20 / February / 2014, 01:37:40 »
Yes it was memory issue. I just cleaned with collectgarbage("collect") and it gone.
This shouldn't generally be required, but it could help if memory was very low. It is also possible for particular script code to generate a lot of garbage.
Quote
I use default motion detector script with continuous shot during 5 seconds. There is another romlog file that I got after about 8 hours of work. What can it be? I couldn't find it in this forum.
It looks like the "too many files open at once" one, which is line 451 on many cameras. This might happen if your script uses log files while shooting.

You post the actual script you are using?
Quote
Does the compiled program  a1400-100b-1.3.0-3359-full-aram-test-1.zip have a different solution to prevent memory crash?
It makes more memory available. As mentioned in my earlier post, it would be nice to know how much memory is free on this camera, for both the normal build and my test build.
Don't forget what the H stands for.

*

Offline nafraf

  • *****
  • 1308
Re: A1400 porting thread
« Reply #65 on: 20 / February / 2014, 08:25:25 »
trunk 3361
GCC 4.6.0
Free Memory 627816 bytes
CHDK Size   146680 bytes
Loaded at 0x15A048

a1400-100b-1.3.0-3359-full-aram-test-1.zip
GCC 4.5.1
Free Memory 629064
CHDK Size   148408 bytes
Loaded at 0x15A048

*

Offline timgor

  • ***
  • 150
Re: A1400 porting thread
« Reply #66 on: 20 / February / 2014, 11:40:56 »
Quote
You post the actual script you are using?

this is my actual script that I'm using with camera in continuous mode shooting
Code: [Select]
...
repeat
    zones = md_detect_motion( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
    if( zones > 0 ) then


    ----continuous shooting during 5 seconds----------
    press("shoot_half")
    repeat sleep(100) until (get_shooting() == true)
    press("shoot_full")
    sleep(5000)
    release("shoot_full")
    release("shoot_half")

    --------- delete older files until 1Gb is free-----------
    local lst = os.listdir("A/DCIM", false)
    table.sort(lst,function(a,b) return os.stat("A/DCIM/"..a).mtime < os.stat("A/DCIM/"..b).mtime end) 
    for _,subdir in ipairs(lst) do   
        for i = 1,9999 do
            if(get_free_disk_space() > 1000*1024)  then break end
            os.remove("A/DCIM/"..subdir.."/IMG_"..string.format("%04d", i)..".JPG")   
        end
    end


    end
until (false)


Quote
It looks like the "too many files open at once" one, which is line 451 on many cameras. This might happen if your script uses log files while shooting.

What do you mean "too many files open at once"? Is it about files opened by script like "os.remove" and "os.listdir" functions or you mean that chdk can open files and modules behind the scene? What functions use log files during the script performance? is there any way to avoid log files?


*

Offline reyalp

  • ******
  • 13667
Re: A1400 porting thread
« Reply #67 on: 20 / February / 2014, 23:56:23 »
What do you mean "too many files open at once"? Is it about files opened by script like "os.remove" and "os.listdir"
Yes

Quote
What functions use log files during the script performance? is there any way to avoid log files?
I meant if your script was creating a log file, either using console log or io functions. Your script doesn't appear to be doing either of these.

When you shoot in continuous mode the cameras buffers quite a bit, so it can still be writing for a while after you release the shutter. I suspect putting some delay between the release and the delete would avoid this issue. I'm not sure how long, the camera probably blinks an LED while it's writing the files, and when that's done it should be safe to continue.


Free memory doesn't look to bad with the autobuild, but the loop could generate a lot of garbage quickly. It would probably be somewhat less if you put everythign sin the string.format like
Code: [Select]
string.format("A/DCIM/%s/IMG_%04d.JPG"",subdir,i)
since this would only create one unique string per iteration.

The free memory looks about the same with the two builds, but I forgot the debug display actually shows the largest free block, so that is expected. The output of get_meminfo().free_size should give the total. Since my build OK, I'll enable ARAM in the 1.3 autobuild, which should add another ~140k.
Don't forget what the H stands for.


*

Offline timgor

  • ***
  • 150
Re: A1400 porting thread
« Reply #68 on: 21 / February / 2014, 11:40:23 »
Thanks. It looks like it's really conflict between shooting and immediate io functions call after that. I already had it for a slow card more frequently some sleep(...) function really helps to avoid it.

Re: A1400 porting thread
« Reply #69 on: 07 / March / 2014, 17:29:47 »
I just got the firmware up and running on my a1400 and I ran into a snag with the following script.  When I copied this script .bas into the Scripts folder on my card and tried to load it in CHDK, nothing happens.  CHDK doesn't take me to a file selection page when I select "Load Script From File". 

I'd appreciate any help on how I can get script files to load.

I'm using this CHDK version: a1400-100b-1.3.0-3369-full_ALPHA.zip

rem Author - Keoeeit
 rem Upgraded by Mika Tanninen
 @title Ultra Intervalometer
 @param a Delay 1st Shot (Mins)
 @default a 0
 @param b Delay 1st Shot (Secs)
 @default b 0
 @param c Number of Shots (0 inf)
 @default c 0
 @param d Interval (Minutes)
 @default d 0
 @param e Interval (Seconds)
 @default e 10
 @param f Interval (10th Seconds)
 @default f 0
 n=0
 t=(d*600+e*10+f)*100
 if c<1 then let c=0
 if t<100 then let t=100
 g=(a*60)+b
 if g<=0 then goto "interval"
 for m=1 to g
  print "Intvl Begins:", (g-m)/60; "min", (g-m)%60; "sec"
  sleep 930
  next m
 :interval
   n=n+1
   if c=0 then print "Shot", n else print "Shot", n, "of", c
   shoot
   if n=c then end
   sleep t
   goto "interval"

 

Related Topics