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
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.
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!
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…
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.
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!
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?
The backtrace retrieval has just got stuck again.
This time with current firmware, and it was the current application that crashed.
The sequence:
The application crashed
When the unit restarted, DS automatically retrieved the backtrace, decoded & displayed it - all worked fine (but takes ages!)
I fixed the problem, rebuilt & downloaded the corrected app
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’
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.
Clickingthe ‘X’ button to close the dialogue does nothing (the ‘Details’ button does still respond).
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??!
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.
