Test #1: 3s delay to dcimdl , dcimdl memory sniff ON, 1M JPG, 101 myshoots, NO FAIL, stopped by me
Test #2: 200 ms delay to dcimdl, dcimdl memory sniff OFF, 1M JPG, 60 myshoots, DOS screen clean NO FAIL, stopped by me
The build I posted has CAM_FIRMWARE_MEMINFO, which means it uses firmware functions to get the available memory instead of the malloc hack mentioned earlier. This suggest to me that the earlier instability might have been caused by the malloc hack, and thus the extra memory debugging calls would have *decreased* stability. I have firmware meminfo enabled on all my cameras, so I wouldn't have seen the same thing. I'll try without though...
Test #3: 200 ms delay to dcimdl, dcimdl memory sniff OFF, 1M JPG & 15MB DNG, FAIL after 7 myshoots (14 files downloaded successfully), failed on DNG, JPG not reached.
Exception!! Vector 0x10
Occured Time 2012:09:11 19:00:00
Task ID: 29491262
Task name: FolderCreate0
Exc Registers:
...
This romlog is quite different from the others. The other ones were in PhySw task, which is one we modify. We don't do anything with FolderCreate0. It's also an invalid memory access exception, rather than an assert. The name suggests that it might be responsible for creating the image folders. In this case, you might try only removing the files from within the folders instead of removing the folders themselves.
I know you'll have something to say about the short delay // and I do have questions about why it works too in test 2 and even in test 3. Test 3 takes several good seconds to save both files to SD, way beyond 200 ms. Hmmmm?
Shoot waits for most of the shooting process to complete. In particular, it shouldn't return until CHDK raw is complete, if it's enabled.
edit:
since firmware meminfo obviously works on this camera, I'll check that in in the release branch.
edit:
The ReadFDir.c Line 96 assert would be triggered by a malloc failure, which matches the conclusion above. The amount of memory it tries to allocate is 32k
edit:
The FolderCreate0 romlogs are bizarre.
ROMLOG_55 is vector 0x04 = invalid instruction, while romlog_aa is invalid memory access
In both cases, PC is not a ROM value or a CHDK code value.
LR in both cases is 0x000C5BC9 which is inside CHDK Lua thumb code. The stack also looks like it's in thumb code. Lua should only run in PhySwtask, certainly not FolderCreate0... Possibly a corrupted TCB ?
Next time when you get the chance please point me to your comment.
http://chdk.setepontos.com/index.php?topic=8613.msg90679#msg90679The commands in dcimdl will only return when they are actually complete.
If you think about something like download, it can't possibly return until it's done (all the data is downloaded from the camera). rm could be fire and forget, but it's not.
