Remote backtrace decoding [SOLVED]


#1

Hi,

DS 2.2.0 fixed our backtrace decoding and now the next step is to remotely decode from units in the field. We are able to send the hex string to a server but would like to know the steps of using this with the .dwl/.axf files from the build to decode the backtraces. Not sure if its possible yet as I saw this post:

Our Traces with an example of the hex string using, adl_errStartBacktraceAnalysis, adl_errRetrieveNextBacktrace and adl_errEraseAllBacktraces:

~C

Info:
Embedded Module: SL Series (SL6087)
Firmware: R7.47.0.201202010317
Open AT OS Package: 6.37.0.201202060950
Developer Studio: 2.2.0.201205041104-R9457
OS: Windows 7 64-bit


#2

Was thinking, is it possible to write these hex values to some part of the memory on a local module and then have developer studio decode it from there?


#3

You can actually do it by saving the bytes (and not the hexa string, obviously) to a binary file.
From there, in DS, create a virtual port pointing on this file; you’ll have to provide additional information (FW running on the module, module type, application’s AXF file).
Then, DS will decode the backtrace when you’ll start “playing” the file content.


#4

Ok yes converted to bytes and saved to a binary file. With the virtual port must I place the binary file in the recording field?
If I do then the result in the traces is:

2012/05/22;13:28:14:372;001;30;1;Current OAT Task index : 0

But no backtraced decoding is started.


#5

Yes.
Did you also configure correctly firmware settings + your application AXF file on the virtual port creation?
If this is OK, please send the hexa string/binary file you retrieved from the ADL API, to let us check if it is somehow corrupted…


#6

Yes 100% sure the firmware + AXF file is correctly configured. Attached is the generated .bin file. Is there a program which converts the hex to bytes and saves which I could use? I wrote a small program to do it because the tools I found don’t work in win7 64-bit so could be an implementation error.

Wanted to know the adl_errRetrieveNextBacktrace() does it return a single backtrace at a time, i.e. 1 Error with all the function calls: (Results below are found with DS v2.2.0 without the AXF file, does decode correctly if supplied)

adl_errRetrieveNextBacktrace():
Out of range callback address (ARM Prefetch Abort caught at 08000418, Current Task 0x1F by CP15 )
Unknown function (8000418)
Unknown function (1ec48c)
Unknown function (2c36a6)

or should i do
adl_errRetrieveNextBacktrace():
Out of range callback address (ARM Prefetch Abort caught at 08000418, Current Task 0x1F by CP15 )

adl_errRetrieveNextBacktrace(…):
Unknown function (8000418)

adl_errRetrieveNextBacktrace(…):
Unknown function (1ec48c)

adl_errRetrieveNextBacktrace(…):
Unknown function (2c36a6)


#7

Slightly updated results attached new .bin file + normal hex file for comparison:

I did the:

size = adl_errRetrieveNextBacktrace ( backtraceHandle, NULL, 0);

untill i read all backtraces into some stringstream and on the 3rd read the size returned ADL_RET_ERR_DONE so stopped reading. This file im now sending to a ftp server for easier use.

In the traces im getting one extra line because of the extra adl_errRetrieveNextBacktrace(…) (previously only read once)

2012/05/25;13:35:32:842;001;30;1;Current OAT Task index : 0
2012/05/25;13:35:32:904;001;27;1;ARM Data Abort caught at 00275EDC, Current Task 0x1F by CP15

so getting closer but still no backtrace decoding is started.


#8

Regarding the files, it seems there is a mistake in the reading logic… Backtrace frames start with a “\x04\x0f\x0a\x05” pattern, but in your case, the bytes aren’t correctly ordered: both in text and bin file, the bytes are “40 f0 a0 50”.
The strangest thing is that trace frames preceding the backtrace are well ordered since DS accepts to decode them…

Maybe should you have a look to the “Bug” sample code, and even try it to see if it can retrieve well-formed backtrace frames.


#9

Thanks for the feedback, that hint with what the backtrace frame starts helped in finding my bug. It was in the communication and the conversion from hex back to bytes. With the conversion and transmission it was inverting all bytes which start in x0 i.e. \x04 became \x40 … the parts where the frame was correctly decoded didnt have any bytes starting in \x0 so thought my conversion was right.

Thanks again for the feedback daav.