Here are some useful techniques for debugging programs on the Aibos
Apparently, this was a pretty useful tool. I haven't tried it, though. (Peter)
9/10/03:
Version 2.1 of mi-pal crash tools (for analysing Aibo crashes) is
up on our website:
Mi-Pal Team Resources (The link still says Crash Debug Tools but it's version 2.1 trust me)
or just grab it directly at: Tarred+Gzipped debug tool
New features: * Its new and improved with less false positives. * A makefile. * More subdirectories. * Many more source files.
---
Dear SONY-Aibo league participants.
In response to the request from many, Team GRIFITH is happy to release its CHRASH ANALYSIS TOOLS under GPL. You can get them from our WEB-site http://gucis.cit.gu.edu.au/%7Emi-pal/ under Crash Debug Tools
Please acknowledge as per GPL.
Thanks
Vlad team leader
I didnt see any sections on the wiki about this. But, this is really helpful while debugging code. If any of your code crashes at startup, or some other time, and the messages that you print out are not of any help, then, it means that the system has thrown an exception. Now, its not possible to get out of this state unless you look at emon.log. When the AIBO crashes, do the following :
Make sure that /usr/local/OPEN_R_SDK_ERS7/bin/ is included in your $PATH.
mount /memstick
cd /memstick/open-r
cp emon.log mydir
cd mydir
umount /memstick
Basically, copy emon.log from the memstick to somewhere. Now, do
sample/Crash/util/emonLogParser emon.log
This will tell you which object is responsible for the crash. Call this crashedObj. Now do,
sample/Crash/util/emonLogParser emon.log crashedObj.nosnap.elf
crashedObj.nosnap.elf is the file that resides in the directory in which you have the crashed object. When you do the above, you will see information that pertains to which symbol, or function in your source code caused your object to crash.
Now run mipsel-linux-objdump -S crashedObj.nosnap.elf > dump.txt to get a disassembly of your object, along with a listing of the original source. Exmaine dump.txt for the address of the crash, which should be the second-to-last number that the emonLogParser spits out.
This is really useful in debugging. Otherwise, we just have to put our trust in the lord, and pray, when something crashes.
You usually use printf and cout to output characters for debugging
In the OPEN-R environment, several objects run concurrently, and there is a chance that the displayed characters from each object are mixed together on-screen. You should use the macros OSYSPRINT and OSYSLOG to avoid this problem. In OSYSPRINT() and OSYSDEBUG(), you can specify the same arguments as ones used in printf(). When the symbol OPENR_DEBUG is not defined, OSYSDEBUG() is replaced with a null string. OPENR_DEBUG is defined by using the compiler option DOPENR_DEBUG.
OSYSPRINT(( test: %d\n , x, y)); OSYSDEBUG(( Hello \n ));
The max length of the displayed characters in OSYSPRINT and OSYSDEBUG is 243 characters including the terminating null character. OSYSLOG1 is a macro for displaying errors. An error level is specified as the first argument. In OSYSLOG1, a line feed is automatically added at the end of the string.
OSYSLOG1((osyslogERROR, This is error! ));
The following characters are displayed as the result of OSYSLOG1.
[oid:80000043,prio:1] This is error!
The numeric value after "prio:" is the error level specified in the first argument. You can specify the following error levels for the first argument of OSYSLOG1.
prio oid/prio Value of prio ==================================================== osyslogERROR Displayed 1 osyslogWARNING Displayed 2 osyslogINFO Displayed 3
For details on more advanced debugging techniques and for fixing/detecting crashes, see the Programmer's Guide.