advanced topic: application logging

[pionara]

applicable units:

z110-140, f10-40, f920-f940, x920-x940, x9310, x9220, u310, f310-320

(all of the above units are based on same software. well 3x0 series are really different units but share nearly identical APL codebase)

 

applicable users:

advanced users only. if you dont know what you are doing, hit the back button and pretend you never read this post!

 

So while trying to research various mysteries I keep seeing lots of juicy logging facilities all over the pioneer code. There are some debugging/maintenance menus where you can turn on various logs, but I'm still trying to find out how access to these menus are granted. In the mean time, I was able to find out enough information about how logging works to edit the LogState.dat to manipulate logging behavior. I will share the info I have and how it can be useful.

 

edit: i have broken into maintenance menu on these units... there is a shitload of dangerous but really cool stuff. Found out more logging info from this...

 

The file is normally kept at USER\RW\LOG\LogState.dat

 

LogState.dat holds the persisted "logging" settings for the unit. screenshot:

 

That has a few key edits over the default LogState.dat (you will get default file recreated if you delete the existing one).

 

Note that this is little-endian since it's ARM.

byte 1c should be 04 (not sure why)

byte 00: Logging enable (01) or disable (00)

byte 01: "data clearness at startup", on = 01, might be for truncating current logfile at startup

byte 02: "immediate output", on = 01 (as opposed to delayed output?)

byte 03: "cache function at file output", on = 01 (related to immediate output?)

byte 04: "action at data full" (what to do when running out of space?)

00 = "1 file stop"

01 = "1 file overwrite"

02 = "some files stop"

03 = "some files overwrite" (seems to be default?)

 

byte 08: output location of the log:

01 = flash disk (USER\RW\SYSLOG\LOG*.TXT)

02 = SD card (SD\SYSLOG\LOG*.TXT). In order for logging to be active to this location, presense of empty file, SD\Log.ini, is required. This may also work for USB

 

byte 20: "count output", on = 1, havent tested yet, but i suspect this will autoincrement the log file numbering on each boot

 

offset 24-27, (32 bit dword) - log timestamp?. This is set dynamically later and persisted. Not so interesting for me.

offset 28-2b, (32-bit dword) - log filename index. e.g., 03 = filename of LOG00003.TXT.

 

the real meat and potatoes - the log masks. There seem to be 4 separate log masks. Here are the default, empty masks and their locations:

0c - 0f = 0x10000000

10 - 13 = 0x20000000

14 - 17 = 0x40000000

18 - 1b = 0x80000000

 

By default these masks are all bits off, so nothing logged. The real magic comes when you find some sections of the code that are making calls to AL_Log::Output(...). first arg (R0) to this will be the log mask for this kind of event.

 

Various libraries/classes will have different log masks.

For example, in RenewalIFLib.dll, there are a few main clases:

AL_AUTH_*::* classes (for encryption/auth funcs) use 0x20080000

AL_VER_*::* classes (for version management funcs) use 0x20040000

 

If I want to see both of these logged, then I need to set the 0x20000000 log mask to 0x200c0000 (both desired masks ORed together) so i set offset 10 to 00 00 0c 20 (remember byte order is little endian)

 

So in addition to regular logging, there are also some calls to "error" logging functions (AL_Error::ErrorRec - which seems to be handled a bit differently from regular logging) however you can still have these logged also. the mask to log error stuff is 0x12000000.

 

Also for fun, if you are really dangerously curious like me - you can turn on ALL LOGGING!!. Just set all 4 log masks (to all FF), i.e., 0x1fffffff, 0x2fffffff, etc etc. This is what I like to call LOG_LEVEL=LUDICROUS

But be warned - It will slow your avic down and could fill up your disk(s). Use this along with any logging cautiously and sparingly, as any logging gives a performance hit and requires more resources.

 

Also, be warned - logging can expose private information such as gps location, unit serial number, maybe even phone numbers, etc depending on the log level. So be careful who you share these with.

Edited November 4, 2012 by pionara

[pionara]

update: manually editing logstate.dat by hand is totally unnecessary now that we have access to maintenance menus which have direct control over all of these as "log setting" submenu:

 

http://avic411.com/index.php?/topic/35531-advanced-topic-hidden-debug-menus/