Sysprogs forums › Forums › VisualGDB › Help with ARM Semihosting
- This topic has 9 replies, 2 voices, and was last updated 5 years, 2 months ago by support.
-
AuthorPosts
-
September 18, 2019 at 16:26 #25823sidpriceParticipant
Sorry for the many posts recently, I have been away from VGDB for a while and have forgotten some of the features.
I have enabled the fast semihosting framework and rebuilt my stm32f401re project, however I am not seeing any semihost window or messages. What should I check to make this work.
Many thanks,
Sid
September 18, 2019 at 16:32 #25824supportKeymasterHi,
Please follow our Semihosting tutorial to get familiar with the related settings and mechanisms.
BTW, we have over 300 different tutorials showing various aspects of VisualGDB and the supported targets, so if you don’t feel comfortable with some VisualGDB features or settings, feel free to search and follow other relevant tutorials to get back on track.
September 18, 2019 at 16:34 #25825sidpriceParticipantMore information:
I have made a little progress, now I am getting an exception on line #58/59 of “FastSemihosting.cpp” :
asm volatile(“mov r0, %1; mov r1, %0; bkpt %a2” ::”r”(&s_FastSemihostingState), “r”(SysprogsSemihostingReasonBase + kInitializeFastSemihosting), “i”(AngelSWI)
: “r0”, “r1”, “r2”, “r3”, “ip”, “lr”, “memory”, “cc”);Received a SIGTRAP: Trace/breakpoint trap occurred
September 18, 2019 at 16:36 #25826supportKeymasterPlease try following the tutorial EXACTLY and ensure it works as described. Then try comparing your setup with the tutorial to understand which of the differences could be causing the issue.
September 18, 2019 at 16:46 #25827sidpriceParticipantYes, the example code works for both normal semihosting and fast semihosting.
Note that this project uses libOpenCM3 and not HAL. Semihosting has previously worked for the project.
Sid
September 18, 2019 at 16:50 #25828supportKeymasterSorry, it looks like something about libOpenCM3 might be interfering with semihosting. As it is a 3rd-party component that does not come from VisualGDB, it is hard to suggest anything specific.
Our best advice would be to create a project as similar as possible to the one that works and then try comparing various settings of the projects that behave differently to find a setting that is causing the incorrect behavior.
September 18, 2019 at 16:54 #25829sidpriceParticipantThe exception I am getting is in the call to “puts”, this suggests that the issue is not related to libOpenCM3.
Sid
September 19, 2019 at 02:59 #25831supportKeymasterSorry, unfortunately we are not able to review specific projects and locate the settings that have been configured incorrectly as a part of our regular support. If the semihosting works for a newly created project, the issue is specific to a particular project instance and the only way to get it to work again would be by comparing the 2 projects and eliminating the differences between them.
September 24, 2019 at 00:56 #25876sidpriceParticipantI have checked my project settings, as well as I can, against the demo project and see nothing that looks wrong. When I last worked on this, some months ago, semihosting worked for me. I would really appreciate some help in tracking this down.
The failure mode is different for the regular and the fast semihosting. With the regular an exception is thrown when either puts or printf is called. With fast semihosting the following line in FastSemihosting.cpp causes an exception:
asm volatile(“mov r0, %1; mov r1, %0; bkpt %a2” ::”r”(&s_FastSemihostingState), “r”(SysprogsSemihostingReasonBase + kInitializeFastSemihosting), “i”(AngelSWI)
: “r0”, “r1”, “r2”, “r3”, “ip”, “lr”, “memory”, “cc”);Again, I understand you can’t debug user project settings, however, I am completely lost as to how to resolve this.
September 25, 2019 at 15:52 #25904supportKeymasterSorry, if the 2 projects behave differently, something either about the project structure, or about the project settings is responsible for the difference.
Normally, the line should cause a special type of exception that would be intercepted by VisualGDB’s semihosting logic, however if it doesn’t happen, something interferes with the exception reporting mechanism, preventing VisualGDB from recognizing it.
The best way to diagnose this type or errors would be to start with a working project and slowly change it one step at a time until it is 100% equivalent to the broken one (i.e. uses the same sources, produces a comparable output, etc). If at this point the 2 projects still behave differently, simply use the new project file instead of the old one (although checking it into source control over the old one will likely reveal some differences).
-
AuthorPosts
- You must be logged in to reply to this topic.