Pixeldoc2000 (talk | contribs) m (Printf and more) |
Waterwingz (talk | contribs) m (→Intruduction) |
||
(25 intermediate revisions by 5 users not shown) | |||
Line 2: | Line 2: | ||
| __TOC__ |
| __TOC__ |
||
|} |
|} |
||
− | == |
+ | ==Introduction== |
This page collects tools and techniques for debugging CHDK code |
This page collects tools and techniques for debugging CHDK code |
||
Line 41: | Line 41: | ||
* In some parts of the code, the stack may not be properly set up, in which case any variables should be static or global. |
* In some parts of the code, the stack may not be properly set up, in which case any variables should be static or global. |
||
* If you want to put this code in an __attribute__((naked)) function, you should also avoid using local variables. In general you should not put any C code in these functions. |
* If you want to put this code in an __attribute__((naked)) function, you should also avoid using local variables. In general you should not put any C code in these functions. |
||
+ | * In some parts of the code - especially early in the booting process - the use of delay loops to actually blink the camera LED can potentially disrupt the boot timing. It is safer to simply turn on the LED rather than blink it. |
||
+ | <source lang="C"> |
||
+ | #define LED_PR 0xc0220134 // your LED address |
||
+ | volatile int *p=(void*)LED_PR; |
||
+ | *p=0x46; |
||
+ | </source> |
||
+ | .. |
||
====Assembler==== |
====Assembler==== |
||
Line 47: | Line 54: | ||
// for testing, blink LED at 0xC0220130 10 times |
// for testing, blink LED at 0xC0220130 10 times |
||
LDR R3, =0xC0220130 |
LDR R3, =0xC0220130 |
||
− | MOV |
+ | MOV R1,#10 |
− | + | 1: |
|
MOV R2, #0x46 |
MOV R2, #0x46 |
||
STR R2, [R3] |
STR R2, [R3] |
||
MOV R0, #0x8000 |
MOV R0, #0x8000 |
||
− | + | 2: |
|
− | SUB R0,R0,#1 |
+ | SUB R0,R0,#1 |
− | CMP R0,#0 |
+ | CMP R0,#0 |
− | BNE |
+ | BNE 2b |
+ | |||
MOV R2, #0x44 |
MOV R2, #0x44 |
||
STR R2, [R3] |
STR R2, [R3] |
||
MOV R0, #0x8000 |
MOV R0, #0x8000 |
||
− | + | 3: |
|
− | SUB R0,R0,#1 |
+ | SUB R0,R0,#1 |
− | CMP R0,#0 |
+ | CMP R0,#0 |
− | BNE |
+ | BNE 3b |
+ | |||
⚫ | |||
⚫ | |||
⚫ | |||
+ | </source> |
||
+ | A safer version of this suitable for inserting inline into the CHKD boot.c, capt_seq.c and movie_rec.c files is |
||
⚫ | |||
+ | <source lang="c"> |
||
⚫ | |||
+ | " STMFD SP!, {R0,R1} \n" |
||
⚫ | |||
+ | " LDR R0, =0xC02200D4 \n" |
||
+ | " MOV R1, #0x46 \n" |
||
+ | " STR R1, [R0] \n" |
||
+ | " LDMFD SP!, {R0,R1} \n" |
||
</source> |
</source> |
||
+ | Remember to change the 0xC02200D4 value in the second line to the address of your camera's LED>. |
||
===Using LEDs from Canon Basic/Eventprocs=== |
===Using LEDs from Canon Basic/Eventprocs=== |
||
Line 75: | Line 93: | ||
When the canon firmware crashes, it will normally write the current registers, a stack dump, and the recent entries from the camera log to internal flash memory and then shut down. This is generally referred to as the romlog. |
When the canon firmware crashes, it will normally write the current registers, a stack dump, and the recent entries from the camera log to internal flash memory and then shut down. This is generally referred to as the romlog. |
||
===Reading the romlog=== |
===Reading the romlog=== |
||
− | + | As of changeset 1432, the romlog can be saved from the CHDK menu, using "miscellaneous stuff->Debug Parameters->Save ROM crash log" |
|
+ | |||
+ | The romlog can also be saved to to a file using [[Canon_Basic/Scripts/Romlog]] or [[Lua/Scripts:Standard/Test/Romlog]] |
||
+ | |||
⚫ | |||
+ | * Some older vxworks cameras will automatically shut down after saving the log. This is normal. |
||
+ | * If the camera has never crashed, the romlog function will fail. |
||
===Interpreting the romlog=== |
===Interpreting the romlog=== |
||
− | + | Text below refers the the plain text romlogs produced by DryOS and some later vxworks cameras. Older vxworks cameras output the romlog in a binary format, some information is available in this forum thread http://chdk.setepontos.com/index.php?topic=5394.0 |
|
− | The first line of the romlog describes the kind of error that occurred. |
+ | The first line of the romlog describes the kind of error that occurred. Known errors include ASSERT, EXCEPTION, WATCHDOG and HARDWARE DEFECT. ASSERT and EXCEPTION are most commonly encountered in CHDK development. The remainder of the log varies slightly depending on the error. |
Example assert |
Example assert |
||
Line 133: | Line 157: | ||
The exception vector tells you what kind of exception occurred. Descriptions of the exception handling process can be be found in the [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0240b/index.html ARM9E-S Core Technical Reference Manual]. |
The exception vector tells you what kind of exception occurred. Descriptions of the exception handling process can be be found in the [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0240b/index.html ARM9E-S Core Technical Reference Manual]. |
||
+ | Example DryOS Panic |
||
+ | <pre> |
||
+ | System Panic: Module = 64, Panic = 4 |
||
+ | Occured Time 2011:04:03 13:46:30 |
||
+ | StackDump(0x2FCED0 - 0x2FCF50): |
||
+ | 0x002FCED0 |
||
+ | 0x0028CAB8 |
||
+ | 0x00000000 |
||
+ | 0xFF81C2E0 |
||
+ | 0x00000000 |
||
+ | 0x00000001 |
||
+ | ... |
||
+ | </pre> |
||
+ | Not clear what the Module and Panic numbers mean. |
||
+ | |||
+ | Example hardware defect |
||
+ | <pre> |
||
+ | HARDWARE DEFECT!! ShutdownReason[9] ErrorNo[41] |
||
+ | Occured Time 2011:12:11 21:02:23 |
||
+ | 00000550: UI:PB.CreateE |
||
+ | 00000560: UI:DisplayPhysicalScreenCBR |
||
+ | 00000560: UI:AC:StartPB |
||
+ | 00000560: UI:DispSwCon_TurnOnDisplayDevice |
||
+ | 00000560: UI:AC:EBtn |
||
+ | 00000560: UI:PB.Start |
||
+ | </pre> |
||
+ | Note the above appears to be triggered by CHDK in this case, not an actual hardware defect. [http://chdk.setepontos.com/index.php?topic=6341.msg77822#msg77822 thread] |
||
===Common Exception Vectors=== |
===Common Exception Vectors=== |
||
− | In CHKD debugging, the most commonly encountered exception is 0x10 Data abort. This occurs when the code attempts to access an invalid memory address. 0x4 Undefined Instruction is also is also common, caused by bad code pointers or stack corruption. |
+ | In CHKD debugging, the most commonly encountered exception is 0x10 Data abort. This occurs when the code attempts to access an invalid memory address. 0x4 Undefined Instruction is also is also common, caused by bad code pointers or stack corruption. A NULL function pointer can trigger 0x0 Reset. |
{| border="1" summary="Exception vectors" |
{| border="1" summary="Exception vectors" |
||
!Exception |
!Exception |
||
Line 183: | Line 234: | ||
You can search these dumps for addresses that appear in the romlog, which will help you find the corresponding C source. Note that Thumb addresses may appear in the stack dump or registers with the lowest bit set. |
You can search these dumps for addresses that appear in the romlog, which will help you find the corresponding C source. Note that Thumb addresses may appear in the stack dump or registers with the lowest bit set. |
||
− | + | The [[CHDK-Shell]] tool will save dumps to bin/logs/dump-{cameraname}-{firmware}.txt '''by default'''. This is controlled by the checkbox named "ELF objdump", just above the "Compile Selected" button. You can also disable "Compile Options > Skip GMAKE clean AFTER compilation" to keep them in the original location. |
|
+ | |||
+ | ==Debugging modules== |
||
+ | CHDK version 1.1 and later uses the [[Module System]] to run some code from loadable modules. This can make debugging more difficult be because the module addresses are not known in advance. |
||
+ | |||
+ | In CHDK 1.2, turning on module logging in the modules menu will cause module load addresses to be recorded in A/MODULES.LOG. |
||
+ | |||
+ | '''Note''' The recorded address is the at the start of the module. This includes a 36 byte header, so you need to add 36 to get the code start address. |
||
+ | |||
+ | Once you have the code start address, you can disassemble the corresponding .elf with symbols and correct addresses using |
||
+ | |||
+ | arm-elf-objdump -d -r -x --adjust-vma=<code start address> mod.elf > mod.dumpobj |
||
+ | |||
+ | The debug dump systems in modules/dbg_dump.c can be used record information about loaded modules at specific points in code. |
||
+ | |||
+ | If you only have the .flt of a module, you can use |
||
+ | |||
+ | arm-elf-objdump -m arm -Mforce-thumb -b binary ... |
||
==Memory values== |
==Memory values== |
||
Line 201: | Line 269: | ||
===Memory browser=== |
===Memory browser=== |
||
− | This allows you to interactively view memory addresses. The right/left buttons increment/decrement the address, and the zoom in/zoom out controls the increment size. |
+ | This allows you to interactively view memory addresses. The right/left buttons increment/decrement the address, and the zoom in/zoom out controls the increment size. On cameras without zoom button or zoom lever, the Disp button can be used to change the increment size. |
− | Note that if you attempt to browse an invalid memory location, the camera will shut down with an exception. |
+ | Note that if you attempt to browse an invalid memory location (or the selected memory location holds an invalid address), the camera will shut down with an exception. |
By default, the value of the selected address is also shown in misc debug values, so you can use this to set a "watch" without changing code. |
By default, the value of the selected address is also shown in misc debug values, so you can use this to set a "watch" without changing code. |
||
+ | |||
+ | There is a modified version of this debug tool which adds some functionality, here: http://chdk.setepontos.com/index.php?topic=6635.0 |
||
==Logging camera console output== |
==Logging camera console output== |
||
Line 213: | Line 283: | ||
* [[Event Procedure|ShowCameraLog]] outputs recent entries in the cameras log. (to be described more below!) |
* [[Event Procedure|ShowCameraLog]] outputs recent entries in the cameras log. (to be described more below!) |
||
* [[Event Procedure|Printf]] can be used to send arbitrary text to the camera console (UART). |
* [[Event Procedure|Printf]] can be used to send arbitrary text to the camera console (UART). |
||
+ | * LogPrintf (not an event proc, need to find the address) can send output to the camera log. LogPrintf takes a number as the first argument, followed by a format string and a variable number of additional arguments. The number specifies a prefix that appears on the log message, either SS: or UI:, and may also have other functions. 0x120 is generally used for SS. The camera log does not appear in the camera standard output by default, but recent entries can be sent there using the ShowCameraLog event proc. Recent log entries will also appear in ROMLOGs. |
||
⚫ | |||
===UART redirection (DryOS)=== |
===UART redirection (DryOS)=== |
||
Line 236: | Line 306: | ||
===VxWorks=== |
===VxWorks=== |
||
− | Many VxWorks cameras support the CAM_CONSOLE_LOG_ENABLED #define in camera.h. When this is enabled, camera STDOUT will be sent to A/stdout.txt |
+ | Many VxWorks cameras support the CAM_CONSOLE_LOG_ENABLED #define in camera.h. When this is enabled, camera STDOUT will be sent to A/stdout.txt if it exists. If stdout.txt does not exist, it will not be created. |
Note, this may cause instability, probably because it uses standard IO functions within a device driver. |
Note, this may cause instability, probably because it uses standard IO functions within a device driver. |
||
+ | |||
+ | ===Example=== |
||
+ | The following example shows using the [[PTP Extension]] with the chdkptp client to get console output |
||
+ | |||
+ | con 1> =require('uartr').start('A/TEST.LOG') |
||
+ | con 2> =call_event_proc('ExMem') |
||
+ | con 3> =call_event_proc('ExMem.View') |
||
+ | con 4> =call_event_proc('ShowCameraLog') |
||
+ | con 5> d test.log |
||
+ | A/test.log->test.log |
||
+ | |||
+ | The commands above |
||
+ | # start uart redirection, appending to TEST.LOG |
||
+ | # register the "ExMem" group of eventprocs |
||
+ | # Call ExMem.View, which prints ExMem information to test.log |
||
+ | # Call ShowCameraLog, which prints recent camera log entries to test.log |
||
+ | # downloads test.log |
||
+ | |||
+ | ====Adjusting the size of the camera log==== |
||
+ | |||
+ | The size of the camera log can be adjusted by stopping and restarting it. ShowCameraLogInfo will output the current log level and buffer size to the camera console. The following restarts the camera log with the default log level and a 16k buffer (tested on A540 and D10, you camera may vary) |
||
+ | |||
+ | call_event_proc('StopCameraLog') |
||
+ | call_event_proc('StartCameraLog',0x20,0x4000) |
||
[[Category:Development]] |
[[Category:Development]] |
||
[[Category:DEBUG]] |
[[Category:DEBUG]] |
Revision as of 21:38, 4 May 2014
Introduction
This page collects tools and techniques for debugging CHDK code
LEDs
A simple way to see if a particular code path is reached.
In a complete CHDK port the started() and finished() macros turn on and off the CHDK debug LED . The debug LED is normally the blue direct print LED. On cameras that do not have a direct print LED, a different one will be used. The AF led should NOT be set as the debug LED in any build intended for normal use, because it would interfere with taking pictures.
Using LEDs directly
First, you need to know an LED MMIO address.
TODO link some led finder code.
The LED is turned on by writing 0x46 to the address, and turned off by writing 0x44
C
From C, you can do something like this to blink an LED cnt times. The nops are used to create a delay. The length of the delay will depend on the camera and whether caches are currently enabled, but should be sufficient to see the led blinking.
#define LED_PR 0xc0220134 // your LED address
...
volatile int *p=(void*)LED_PR;
for(;cnt>0;cnt--){
*p=0x46;
for(i=0;i<0x200000;i++){
asm ("nop\n");
asm ("nop\n");
}
*p=0x44;
for(i=0;i<0x200000;i++){
asm ("nop\n");
asm ("nop\n");
}
}
Some things to watch out for
- If you call this code from inline assembler, you need to make sure to preserve any registers. The ASM_SAFE macro may be used for this purpose.
- In some parts of the code, the stack may not be properly set up, in which case any variables should be static or global.
- If you want to put this code in an __attribute__((naked)) function, you should also avoid using local variables. In general you should not put any C code in these functions.
- In some parts of the code - especially early in the booting process - the use of delay loops to actually blink the camera LED can potentially disrupt the boot timing. It is safer to simply turn on the LED rather than blink it.
#define LED_PR 0xc0220134 // your LED address
volatile int *p=(void*)LED_PR;
*p=0x46;
..
Assembler
You might want to blink an LED directly from assembler code
// for testing, blink LED at 0xC0220130 10 times
LDR R3, =0xC0220130
MOV R1,#10
1:
MOV R2, #0x46
STR R2, [R3]
MOV R0, #0x8000
2:
SUB R0,R0,#1
CMP R0,#0
BNE 2b
MOV R2, #0x44
STR R2, [R3]
MOV R0, #0x8000
3:
SUB R0,R0,#1
CMP R0,#0
BNE 3b
SUB R1,R1,#1
CMP R1,#0
BNE 1b
A safer version of this suitable for inserting inline into the CHKD boot.c, capt_seq.c and movie_rec.c files is
" STMFD SP!, {R0,R1} \n"
" LDR R0, =0xC02200D4 \n"
" MOV R1, #0x46 \n"
" STR R1, [R0] \n"
" LDMFD SP!, {R0,R1} \n"
Remember to change the 0xC02200D4 value in the second line to the address of your camera's LED>.
Using LEDs from Canon Basic/Eventprocs
The LEDs can also be controlled using the LEDDrive function, either from Canon Basic or as an Event Procedure.
Camera crash logs (romlog)
When the canon firmware crashes, it will normally write the current registers, a stack dump, and the recent entries from the camera log to internal flash memory and then shut down. This is generally referred to as the romlog.
Reading the romlog
As of changeset 1432, the romlog can be saved from the CHDK menu, using "miscellaneous stuff->Debug Parameters->Save ROM crash log"
The romlog can also be saved to to a file using Canon_Basic/Scripts/Romlog or Lua/Scripts:Standard/Test/Romlog
Notes
- Some older vxworks cameras will automatically shut down after saving the log. This is normal.
- If the camera has never crashed, the romlog function will fail.
Interpreting the romlog
Text below refers the the plain text romlogs produced by DryOS and some later vxworks cameras. Older vxworks cameras output the romlog in a binary format, some information is available in this forum thread http://chdk.setepontos.com/index.php?topic=5394.0
The first line of the romlog describes the kind of error that occurred. Known errors include ASSERT, EXCEPTION, WATCHDOG and HARDWARE DEFECT. ASSERT and EXCEPTION are most commonly encountered in CHDK development. The remainder of the log varies slightly depending on the error.
Example assert
ASSERT!! FsIoNotify.c Line 451 Occured Time 2010:06:26 18:10:53 Task ID: 1441797 Task name: SpyTask SP: 0x002FCE44 StackDump: 0x00000000 0x00000008 0xFF8187F8 ...
The stack dump can help you figure out which functions were called an in some cases what their parameters were. Rather than actually working through all the calls, it is frequently sufficient to just look for addresses that look like code, either ROM or within CHDK address space. Keep in mind that the final entry in the stack dump is the call to assert itself.
Example exception
Exception!! Vector 0x10 Occured Time 2010:05:30 13:05:27 Task ID: 1441797 Task name: SpyTask Exc Registers: 0x0000007A 0x00008000 0x00000050 0x65784500 0x00000006 0x00000000 0x00000005 0x00000014 0x19980218 0x19980218 0x19980218 0x19980218 0x80000000 0x002FCEC0 0x0014C427 0x0014C43E 0x00000033 StackDump: 0xFF812398 0x00002E10 0x00000010 ...
Unlike assert, the exception log includes the CPU registers at the time the exception occurred. The 15th register is LR, 16th register is the instruction pointer (PC), and the 17th is the program status word.
Keep in mind the LR will point to the instruction after the BL instruction, and may have lowest bit set if the call was from thumb code. PC will not have the low bit set in thumb code.
The exception vector tells you what kind of exception occurred. Descriptions of the exception handling process can be be found in the ARM9E-S Core Technical Reference Manual.
Example DryOS Panic
System Panic: Module = 64, Panic = 4 Occured Time 2011:04:03 13:46:30 StackDump(0x2FCED0 - 0x2FCF50): 0x002FCED0 0x0028CAB8 0x00000000 0xFF81C2E0 0x00000000 0x00000001 ...
Not clear what the Module and Panic numbers mean.
Example hardware defect
HARDWARE DEFECT!! ShutdownReason[9] ErrorNo[41] Occured Time 2011:12:11 21:02:23 00000550: UI:PB.CreateE 00000560: UI:DisplayPhysicalScreenCBR 00000560: UI:AC:StartPB 00000560: UI:DispSwCon_TurnOnDisplayDevice 00000560: UI:AC:EBtn 00000560: UI:PB.Start
Note the above appears to be triggered by CHDK in this case, not an actual hardware defect. thread
Common Exception Vectors
In CHKD debugging, the most commonly encountered exception is 0x10 Data abort. This occurs when the code attempts to access an invalid memory address. 0x4 Undefined Instruction is also is also common, caused by bad code pointers or stack corruption. A NULL function pointer can trigger 0x0 Reset.
Exception | Vector address | Description |
---|---|---|
Reset | 0x00000000 | |
Undefined instruction | 0x00000004 | |
SWI | 0x00000008 | |
Prefetch Abort | 0x0000000C | |
Data Abort | 0x00000010 | Happens on access to invalid memory address |
Reserved | 0x00000014 | |
IRQ | 0x00000018 | |
FIQ | 0x0000001C |
Source: ARM9E-S Core Technical Reference Manual
Locating CHDK code from romlog addresses
The CHDK build process writes disassembly dumps of the main CHDK binary. The dump for the main code is stored in core/main.dump
The dump for the loader code (which includes the main code, but not located at the final address) is stored in loader/<camera>/main.dump
You can search these dumps for addresses that appear in the romlog, which will help you find the corresponding C source. Note that Thumb addresses may appear in the stack dump or registers with the lowest bit set.
The CHDK-Shell tool will save dumps to bin/logs/dump-{cameraname}-{firmware}.txt by default. This is controlled by the checkbox named "ELF objdump", just above the "Compile Selected" button. You can also disable "Compile Options > Skip GMAKE clean AFTER compilation" to keep them in the original location.
Debugging modules
CHDK version 1.1 and later uses the Module System to run some code from loadable modules. This can make debugging more difficult be because the module addresses are not known in advance.
In CHDK 1.2, turning on module logging in the modules menu will cause module load addresses to be recorded in A/MODULES.LOG.
Note The recorded address is the at the start of the module. This includes a 36 byte header, so you need to add 36 to get the code start address.
Once you have the code start address, you can disassemble the corresponding .elf with symbols and correct addresses using
arm-elf-objdump -d -r -x --adjust-vma=<code start address> mod.elf > mod.dumpobj
The debug dump systems in modules/dbg_dump.c can be used record information about loaded modules at specific points in code.
If you only have the .flt of a module, you can use
arm-elf-objdump -m arm -Mforce-thumb -b binary ...
Memory values
There are two common ways to inspect memory values in CHDK
Misc debug values
This displays four memory values in the CHDK OSD. The display can be turned on or of in the CHDK menu under miscellaneous stuff->Debug parameters->Show misc. values
By default, the values listed below are shown, but this can be be changed in core/gui.c gui_draw_debug_vals_osd()
u: usb power state 1: the address selected in the memory browser (see below) f: the focus_busy value z: the zoom_busy value
Early in the porting process, you may want to hard code this to always be displayed, and also uncomment the first call to gui_draw_debug_vals_osd() in gui_draw_osd to ensure it is drawn even if some variables are wrong.
Memory browser
This allows you to interactively view memory addresses. The right/left buttons increment/decrement the address, and the zoom in/zoom out controls the increment size. On cameras without zoom button or zoom lever, the Disp button can be used to change the increment size.
Note that if you attempt to browse an invalid memory location (or the selected memory location holds an invalid address), the camera will shut down with an exception.
By default, the value of the selected address is also shown in misc debug values, so you can use this to set a "watch" without changing code.
There is a modified version of this debug tool which adds some functionality, here: http://chdk.setepontos.com/index.php?topic=6635.0
Logging camera console output
Many firmware functions output information to the cameras console. Normally, this is discarded, but it it can be recorded with the following methods.
Some functions that put useful information to the camera console
- ShowCameraLog outputs recent entries in the cameras log. (to be described more below!)
- Printf can be used to send arbitrary text to the camera console (UART).
- LogPrintf (not an event proc, need to find the address) can send output to the camera log. LogPrintf takes a number as the first argument, followed by a format string and a variable number of additional arguments. The number specifies a prefix that appears on the log message, either SS: or UI:, and may also have other functions. 0x120 is generally used for SS. The camera log does not appear in the camera standard output by default, but recent entries can be sent there using the ShowCameraLog event proc. Recent log entries will also appear in ROMLOGs.
UART redirection (DryOS)
DryOS (TODO and possibly late vxworks ?) cameras can redirect UART console output with StartRedirectUART Event Procedure. To use this function, a file named uartr.req must be present in the root of the SD card, and must start with the bytes 0x77 0x21 0xce 0x82 .
StartRedirectUART(int buffer_size,const char *filename)
buffer_size controls how much output is buffered. The value is rounded up to 8192 bytes.
filename is the name of the file to write. If NULL, an name will be automatically picked based on tick count. If a name is given, output will be appended to the file.
The standard CHDK distribution includes the uartr.lua lua module which provides an interface to this.
Note that a sleep() appears to be required between enabling uart redirection and the first output being recorded.
UART redirection may be stopped with StopRedirectUART() .
UART Console
UART Console allow access to Canon Event Shell and DryOs Shell (drysh).
UART pinout on Camera PCB have to be discovered for your Camera. Look SD4000 for example.
VxWorks
Many VxWorks cameras support the CAM_CONSOLE_LOG_ENABLED #define in camera.h. When this is enabled, camera STDOUT will be sent to A/stdout.txt if it exists. If stdout.txt does not exist, it will not be created.
Note, this may cause instability, probably because it uses standard IO functions within a device driver.
Example
The following example shows using the PTP Extension with the chdkptp client to get console output
con 1> =require('uartr').start('A/TEST.LOG') con 2> =call_event_proc('ExMem') con 3> =call_event_proc('ExMem.View') con 4> =call_event_proc('ShowCameraLog') con 5> d test.log A/test.log->test.log
The commands above
- start uart redirection, appending to TEST.LOG
- register the "ExMem" group of eventprocs
- Call ExMem.View, which prints ExMem information to test.log
- Call ShowCameraLog, which prints recent camera log entries to test.log
- downloads test.log
Adjusting the size of the camera log
The size of the camera log can be adjusted by stopping and restarting it. ShowCameraLogInfo will output the current log level and buffer size to the camera console. The following restarts the camera log with the default log level and a 16k buffer (tested on A540 and D10, you camera may vary)
call_event_proc('StopCameraLog') call_event_proc('StartCameraLog',0x20,0x4000)