Use the USB port as a Virtual Serial Port for debugging purposes

Started by jplxpto, July 29, 2012, 02:32:10 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jplxpto

I do not know if it's possible but it would be very interesting to have a channel of communication with the camera. I think, can not use a serial console or even a JTAG is a major limitation in this project.

If it were possible to use the USB port as a Virtual Serial Port for debugging purposes, developers could save much time and simplify many of the tasks of the development process.

With a virtual serial port, you could send debug messages to a computer, allow interaction with the developer. The transfer of small files also not be excluded.

Maybe it was still possible to implement a payload with 'GDB Stubs' allowing use GDB to perform remote debugging.

If this were possible it would be an excellent tool in development.

Sorry if this makes no sense.
It was just one idea that I thought I'd share with you.

This was my first contribution.

jplxpto

It seems that someone had already thought of that before :)

http://chdk.setepontos.com/index.php?topic=6423.msg68017#msg68017

https://groups.google.com/forum/?fromgroups#!topic/ml-devel/A9kwAACsj34%5B1-25%5D


It's interesting when we discover that there are more people think like us. The husdon wrote:

"
I've added some similar functions to Magic Lantern for the 5D Mark II.  It looks like we duplicated each others efforts in reverse engineering the PTP context structure and callback interface.  I added fine grained focus control for interfacing with remote focus controllers like the Impero.

One of my other goals was to build a command console that would work over the PTP interface.  Perhaps it would allow arbitrary Lua commands to be sent, and use the USB as the stdout.  And as an outside goal, I wanted to add a gdb interface so that extensions could be more easily debugged.
"
http://chdk.setepontos.com/index.php?topic=4338.0;wap2

1%

Well you can connect over PTP over usb cable and call any function by address. We did it for sound.

jplxpto

Quote from: 1% on August 13, 2012, 02:53:05 AM
Well you can connect over PTP over usb cable and call any function by address. We did it for sound.

Thank you ... When I can I will do some tests.


g3gg0

there are possibilities.

you can infect the cache to set a jump to your own code at any ROM position. this is working on e.g. 600D.

so you can add a breakpoint anywhere (by placing a "B @myBreakpointFunc") and do some usleep there
until some debugger task that communicates via ptp tells your "breakpoint" to continue and return where it came from.

but what would it help? breakpointing and waiting for user action will for sure raise an ERR70.
this might be useful for debugging ML code - there you dont need cache infection since it runs from RAM anyway.

if someone does the PTP <-> GDB part, i will do the "setBreakpoint" etc functions that require ARM patching etc.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!


SDX

In general, every kind of serial output would be just awesome. Then you could hack lots of equipment to your camera. I am thinking of controlling my timelapse-dolly though the camera.
If the communication also would work the other way around, you could add fx. a distance sensor for some simple AF while filming (at least in theory) or some physical controls (potentiometers, buttons)  for some relevant parameters. Of course that would only be something for the developers to play around with ;)

I have tried several solutions so far. One was a optocoupler through the LED. But it wasn't precise enough to receive valid data. A attempt to use the sound output failed quite quickly when I realized that custom tones can't be played though the audioutput on a 600D, which is the only camera I have available.

So, what do I want to say? Nothing special, just that some sort of serial communication could make people very happy.

nanomad

The 600D should have serial output over two of the battery grip pins. I don't have one so I can't hook it to an oscope but it should be easy to detect
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

jplxpto

With time and work almost anything can happen ... this team has already achieved great things ... this may be one more. I hope one day to do remote debugging to one of these cameras ...

1%

But what kind of serial..... TTL or PC levels? Also, doesn't it have to be enabled somehow... I wish they just put it over USB but I guess they needed console + usb for something else.

/no O-scope yet so someone will have to find it.

QuoteI realized that custom tones can't be played though the audioutput on a 600D

They can but it was really odd volume and outputting through speaker at the same time. Maybe with monitoring off and output routed to headphone this could work but you're kind of a special case here.

jplxpto


If you need to use a voltage converter for the RS232 connection,
you can purchase one of the following cables:

http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm

You know what is the voltage used by pins available on the camera.
Nowadays, many devices use 1.8V and 3.3V and 5V in the past.

g3gg0

well, i implemented a GDB interface in my ARM emulator.
i think i can do it in camera too, using cache hacks.
(using PTP as "gateway")

but you only can debug non-time-critical code like ML tasks or some background tasks.
i am afraid that some watchdog will cause ERRxx when stopping some canon code.

but worth a try.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

1%

I have a TTL converter already for other arm stuff like openwrt but no way to access the pins, maybe piggy back some wires when inserting the grip but from what is said above a little more trouble than its worth.

jplxpto

Quote from: SDX on September 17, 2012, 08:38:11 PM
In general, every kind of serial output would be just awesome. Then you could hack lots of equipment to your camera. I am thinking of controlling my timelapse-dolly though the camera.
If the communication also would work the other way around, you could add fx. a distance sensor for some simple AF while filming (at least in theory) or some physical controls (potentiometers, buttons)  for some relevant parameters. Of course that would only be something for the developers to play around with ;)

I have tried several solutions so far. One was a optocoupler through the LED. But it wasn't precise enough to receive valid data. A attempt to use the sound output failed quite quickly when I realized that custom tones can't be played though the audioutput on a 600D, which is the only camera I have available.

So, what do I want to say? Nothing special, just that some sort of serial communication could make people very happy.

I agree with you ... a channel of communication with the camera would be fantastic.

jplxpto

Quote from: g3gg0 on September 18, 2012, 04:28:37 PM
well, i implemented a GDB interface in my ARM emulator.
i think i can do it in camera too, using cache hacks.
(using PTP as "gateway")

but you only can debug non-time-critical code like ML tasks or some background tasks.
i am afraid that some watchdog will cause ERRxx when stopping some canon code.

but worth a try.


I can work with you in that I can help, and with all that we can be available to debug our cameras.

You mentioned that added the GDB stubs in your ARM emulator. What emulator is? ... It is available for download?

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

jplxpto

"Embedding with GNU: the gdb Remote Serial Protocol"
http://www.huihoo.org/mirrors/pub/embed/document/debugger/ew_GDB_RSP.pdf
http://www.eetindia.co.in/STATIC/PDF/199911/EEIOL_1999NOV03_EMS_EDA_TEST_TA.pdf?SOURCES=DOWNLOAD

"
Other commands
Console output ("O")—optional
Example:
$O48656c6c6f2c20776f726c64210a#55
(Prints "Hello, world!\n" on the gdb
console)
This command allows a debugging
stub to send a text message to the gdb
console. The text to be displayed is
sent in its hex byte equivalent ('H' ==
0x48) and gdb will queue successive
messages until it sees a newline ('\n',
0x0a) character.
This message always originates in
the debugging target; gdb never sends
a console output message to the
debugging target.
"

-------------

Implementing a Debugging Agent for the GNU Debugger
http://neptune.billgatliff.com/debugger.html

"
Console Output (O)
Sent by the target to request output at the gdb console. There is currently no corresponding strategy for gdb to request target console output, or for either gdb or a target to simulate console input.

The argument to this message is a string of data encoded as two-byte hex. Gdb will not display the message until a newline, 0x0a, is received.

The following example sends a "Hello, world!\n" message to the gdb console. Gdb does not respond to this message, other than message acknowledgement.

[target]  $O48656c6c6f2c20776f726c64210a#55

[gdb]
"


I'm thinking of using this command to implement the methods gdb_putc(int c), gdb_puts(char * str) and gdb_printf (...).

I think it should not be difficult to add the command 'gdb console' to ptpcam.
This new command can be listening on port 23 (or another set).
So we can easily use telnet to connect to camera console.