Retrieving Backtraces

DevStudio 1.2.0 connected to Fastrack XTend with 7.4.0.a firmware.

Should DS be able to retrieve & decode backtraces from this unit :question:

I’m pretty sure that the unit does contain some backtraces, but DS won’t display anything.

The device is connected;
The ‘Backtraces[COMxx]’ tab is open
I click the ‘Refresh the content of this view’ button
The ‘Retrieve Backtraces’ dialogue pops up very briefly (barely long enough to read that it is the ‘Retrieve Backtraces’ dialogue), but then just disappears without any message, and the Backtraces tab remains empty.

The Traces viewer is working;
The Heap Memory viewer is working;
It’s just the Backtraces that don’t.

NB: when I refresh the Heap view, the Traces view also gets updated with all the “RTK STATUS” stuff; but, when I try to update the Backtraces view, nothing happens in Traces.

I’ve made a test on a connected Fastrack Suprem with R7.44.0 firmware.

I have used the provided sample bug, downloaded it and run it in order to cause backtrace on my unit.

Then I opened Backtraces view… and I got decoded backtraces (in my case the ‘Retrieve Backtraces’ dialogue was rather long )!

So - does this feature not work with earlier versions of firmware?

I have tried to retrieve backtraces from my connected Fastrack Suprem with 7.4.0.a firmware now.

I still made my test with the ‘bug’ sample… and I got decoded backtraces successfully.

So can I assume you have no backtraces on your unit ?

Please note that the ‘backtraces’ feature is available only in Development mode.

As I said, I’m pretty certain that there are backtraces in there - for one thing, because, when the unit crashes on TMT, it says there is no room for more backtraces!

But I shall have to check properly…

But that is not supported by earlier versions of firmware - see: https://forum.sierrawireless.com/t/at-wdm-undocumented/4792/1

So, again, does this mean that backtraces from earlier versions cannot be retrieved and/or decoded by DS 1.2.0?
That would be a very serious limitation indeed!

And fortunately, this is not (completely) true.
Nevertheless, there is a limitation. Stored backtraces can be decoded if the firmware currently running on the target is exactly the same that the one which was running when the exception occured (since Firmware additional metadata are required to perform the decoding; these metadata are read from Firmware packages installed in your DS, and the correct package version is automatically selected according to the FW currently running on the device).

However, this shouldn’t explain your issue, since:

  • if you don’t have the correct Firmware package installed in your DS, the backtrace view is disabled (and you wouldn’t have been able to click the refresh button)
  • if the running firmware is correct, but backtraces are “old” enough to not match with it, there should be something decoded in your backtrace view (wrong, but at least something).

Please can you attach the DS error log for further investigation?

Last clue: did you click the Clear button? This one clears both backtrace view and target’s memory…

There was something funny with the unit:

When I tried to retrieve the backtraces with an Open-AT application, it also said there were no backtraces.

I used that application to erase all backtraces, and now DevStudio can read & decode any new backtraces from it. :smiley:

Follow-up question:

How does one get DevStudio to decode backtraces that have been extracted from a remote unit :question:

Not possible with 1.2.0 (you know, we had to make choices between release date & features…)
Anyway, we still plan to add this feature in a future release.

Time to start a “Wish List for 1.2.1” thread, then… 8)

Indeed!

Just had the same problem on another unit:
ie, the ‘Retrieve Backtraces’ was doing nothing, despite me being pretty sure that there should be backtraces.

I think DevStudio needs to give an explicit message when it detects that there are no backtraces.

The Open-AT app also reported “no backtraces” - so I did the erase.

I guess this must be something to do with backtraces created by an old version of firmware, that weren’t erased before updating the firmware?

Now, after creating a backtrace, DevStudio says it has retrieved it - but has hung at “Loading unwinding data: Decoding the backtraces”
I have clicked the ‘Cancel’ button - it has gone grey, but has not cancelled the operation!
Clicking the ‘X’ to close the dialogue also has no effect!

The only escape seems to be to close DevStudio.

Ok, point logged

Behaviour seems coherent between DS and Open AT API result… Backtraces are not supposed to “disappear” when FW is upgraded… Sounds strange however, if you’re sure that there were backtraces inside…

Please can you have a look to the error log and attach it?

Remind me - what file is it that you require, and where would I find it?

The easiest way: Ctrl+3, enter “Error Log”, and in the view click the export button.

Will that work if the Studio has been restarted since the problem occurred…?

Yes, all logs are kept until you explicitely ask for them to be deleted

The backtrace retrieval has just got stuck again.
This time with current firmware, and it was the current application that crashed.

The sequence:

  1. The application crashed
  2. When the unit restarted, DS automatically retrieved the backtrace, decoded & displayed it - all worked fine (but takes ages!)
  3. I fixed the problem, rebuilt & downloaded the corrected app
  4. When the unit restarted after the download, DS automatically started retrieving backtraces again - as this is so slow (and I’d already seen the backtrace) I pressed ‘Cancel’
  5. The ‘Cancel’ button goes grey, but the ‘Retrieve backtraces’ dialogue does not close. The little progress animation in the status bar keeps running, but there is no progress.
  6. Clickingthe ‘X’ button to close the dialogue does nothing (the ‘Details’ button does still respond).
  7. Closing the COM port has no effect.

I’ve tried to attach the log file, but the forum refuses to accept it!
After, apparently, uploading the entire file - it then says, “the extension is not allowed”
Couldn’t it have said that before wasting time doing the upload??! :angry:

I tried the following extensions:

  • .log
  • .txt
  • none

What extensions are accepted??

Try .zip for attachments. Was the only one that worked for me!

Thanks for the sequence, we’re going to have a look in order to try improving the performances, and at least make it possible to cancel the operation properly.

Is it possible to disable the automatic retrieval of backtraces at startup?
If not, I think it should be!

May be prompt, “Backtraces detected - retrieve now?” with a “Never ask again” option?
Also, a “just delete” option?