- This topic has 11 replies, 2 voices, and was last updated 2 days, 4 hours ago by
.
-
Posts
-
We have a tricky problem which looks like it needs some tracing. In VisualGDB Properties, I turned Software tracing on and selected a function to trace. All good so far. The debugger had to be restarted and now a cryptic debugging failed message issues. Any help would be much appreciated.
Hi,
Sorry, this looks like the ELF file you are trying to trace contains some non-standard relocation records, so VisualGDB won’t know how to patch it. We can update VisualGDB to dump the exact address of the relocation record so you could try to adjust the code to avoid it, but it may turn out that there are multiple similar records with no easy fix.
We are using a bin file not an elf file. It looks like the relocation is caused by the live tracing. I searched the code for relocate and can only find standard code.
Sorry, that wouldn’t work. You need an ELF file built with relocation records and full debugging symbols.
Thanks for the reply. Would hex files also work? There is no easy way I can see for gcc to make an elf file.
Quick update. I managed to fix the issue which was caused by the command buffer having an extra zero in the array and a length of 1. Resetting the buffer fixes the issue but there is still the question of how this random byte is getting set which is where a trace would be great. I will ask the team if anyone knows how to make an elf file from the arm compiler and come back here to report how it goes with an elf file. Thanks again for the help.
Another update. The issue is still there, and I really need to use the Trace function. I have turned off the bin output file and now the arm GCC compiler generates an elf file. However Visual GDB does not seem to be able to find the file even though it is present in the output folder:
stm32-h7.elf: No such file or directory.
The ELF file should be generated even if the bin file generation is enabled.
The last error looks like you somehow managed to break the project while attempting to get tracing to work.
If nothing works, please try creating a new simple project for the same device from scratch, and verify that tracing works there. If it does, please try comparing the current project layout against the test project layout, to see if there are any differences that could be interfering.
OK, thanks. It looks like an elf file is always generated by gcc.
I did try to load a smaller project and it seems to work. It asked a question about relocating records which I didn’t get on the main project. I will keep trying. Thanks for the info.
With the trace, now that it is working, how do you view the last 1000 lines of code executed? I see that you can add tracepoint events but a trace is when you stop the code and view previous execution.
For example, I am pretty sure another service is coming in and interrupting the code which is why data is going missing. I am not sure how many services we have running but it would in the hundreds so impossible to find without a trace function.
These are two different tracing techniques. To view the last 1000 running lines of code, you would need to use separate J-Trace hardware and have the trace pins properly routed on the board (see this tutorial). Software trace works differently: it patches specific code locations to generate software trace events (ultimately, just write data to a buffer that VisualGDB will decode). So, you would need to think how the program is structured, what code could preempt the main thread, and put tracepoints there to reconstruct what is going on.
- You must be logged in to reply to this topic.