[swineone]

Bumping the thread because these issues are really important to us. Even a partial reply to the easier questions would be good enough for now.

[swineone]

We just found another issue, and we’d love if you could take a look at it.

If a project is created normally (before converting to a standalone project), the Hardware Registers view within Debug -> Windows is available. However, after converting to a standalone project, the Hardware Registers view disappears. I’ve traced this to an incorrectly generated XML file. The <MCUDefinitionFile> tag should be nested within the <EmbeddedProfile> tag, but instead it’s nested within the <InPlaceMCU> tag which itself is nested within the <EmbeddedProfile> tag. It should be a simple fix.

[swineone]

If you mean a linker script file, at least if you’re using a standalone project (i.e. if you followed this tutorial) then it should be in Project -> VisualGDB Project Properties -> Embedded Project, under “Building and Linking”, “Linker script”. However, if it’s a conventional project, then I have no idea how.

[swineone]

I’ve had a look around the Visual Studio extension APIs and indeed it seems like a lot of the things I proposed cannot be implemented directly. However, according to this page, at least the priorities are supplied as a string, so that takes care of proposal #1, and in my opinion proposal #4 as well by writing something such as 0/1 or 0 (1). I could also add more information under the Priority column, such as #2, #3 and #5. Of course this would mean basically hijacking the Priority column for doing other things it wasn’t meant to do, but IMO there are advantages to seeing all the information in a single screen, instead of having to go into a separate properties dialog for each thread.

Here’s a concrete suggestion that shouldn’t be too much work for you: could you modify the interface for the threads plugin, allowing the plugin to supply a string to be passed as the bstrPriority field of the THREADPROPERTIES struct within the Visual Studio API? That should provide a solution for most of the proposals I made above.

Thanks

[swineone]

I found the following directives at the beginning of an STM32F4xx startup file in assembly. Perhaps adding those to the beginning of your file should fix the problem. And yes, it does say cortex-m3 despite the fact that this is a Cortex-M4 CPU; no idea if you can change it to cortex-m4.

.syntax unified

.cpu cortex-m3

.fpu softvfp

.thumb

[Author]

Posts