[codex653]

That’s some fantastic resources! Thank you.

[codex653]

Hmm that’s a bummer. I don’t actually use CMake as my build system (I tend to prefer Boost.Build), so I guess I’ll have to figure something out. I currently use compiler flags to enable/disable various files in the build system to get around the Visual C++ file limitations and it works ok for me.

I might just try converting some of the stm32.xml/props files such that it will switch things out correctly behind the scenes. I have multiple solutions that build as static libraries and then link into a larger project, so it would be very helpful to have built in support for multiple processors at the click of a button.

As another thought, am I able to invoke my own command line builds using VGDB? That way I could use the platform configuration to invoke the correct build command within my projects.

[codex653]

It looks like a combination of the .vcxproj, stm32.xml, and stm32.props are what drive which MCU target gets built for a given configuration. Currently each platform configuration is referencing the exact same stm32.props/.xml file, which is what is changing when I update the “Embedded Project” settings. It would seem like there could be support for multiple embedded targets, but I don’t see how to do that outside of manually editing the files, which sounds like a bad idea.

[codex653]

Thanks so much! That behaves exactly as I hoped and it saved me a ton of headache. I went to debug a project and realized my customized hardfault handler wasn’t being linked in due to the same issue. Turning on the flag linked everything properly and I was able to get to the correct handler! Very very handy flag.

[codex653]

Adding the references worked a treat. Thanks for the new trick! I wasn’t using the command line to specify the library inputs because it can’t parse Visual Studio macros like $(OutDir), which limits the portability of the solution. So personally I would love having the ability to wrap with -whole-archive/-no-whole-archive! 🙂

[codex653]

I’m using MSBuild, but I was explicitly referencing the libraries via the Linker options in the project properties settings. Is there an easier way to do it through references?

[codex653]

I ended up solving the problem. My chip’s startup code is compiled into one of the static libraries that is linked into the larger project. Despite verifying that the vector table IS in there and was compiled with the “__attribute__( ( section( “.isr_vector” ), used ) )” GCC annotation to prevent removal, it’s still being thrown out during linking. In order to fix this, I had to include the startup file in the larger project, which goes against my goal of modularizing the code base.

Is there a way for me to inject --whole-archive/--no-whole-archive into the linker step? I’d rather not have to explicitly reference the interrupt vector in the main project in order to keep that part of the code from the static library.

For reference, I’ve been looking at this tutorial: https://visualgdb.com/tutorials/arm/linkerscripts/

and this StackOverflow question: https://stackoverflow.com/questions/1202494/why-doesnt-attribute-constructor-work-in-a-static-library

• This reply was modified 4 years, 10 months ago by codex653.
• This reply was modified 4 years, 10 months ago by codex653.

[codex653]

I was able to verify that the isr vector table is located at the correct address with both #1 & #2, but I noticed that the .text section was also located at the same address (0x08000000). As a test, I compiled the HAL blinky example project from the project wizard and objdump-ing the output showed me that the .text and .isr_vector symbols are located at two different addresses. Further inspection of the blinky binary shows the expected Reset_Handler address in the second word of the image and the stack address in the first word, as expected…my project shows essentially garbage data.

I’ve attached an image of the objdump output for an example. This seems to be leading me down the right path…

• This reply was modified 4 years, 10 months ago by codex653.

Attachments:

You must be logged in to view attached files.

[codex653]

Whoops! I didn’t realize it had expired. I’ve purchased the support renewal as of a few moments ago.

[codex653]

After using it for around 30 min, this appears to be working much better.

[codex653]

I have also been experiencing this issue quite frequently using the latest VGDB build at the moment (5.4R4 build 3031) and running on VS2019 Community Edition 16.0.0  Preview 5.0 as well as VS2017 Community Edition 15.9.11. I will install the linked VGDB build and test it too.

[codex653]

That’s a bummer! Thanks for the info.

[codex653]

I’m pretty interested in hearing what’s available for this too. I’m nearing a point in my own project where it would be useful to have this kind of information.

[codex653]

Interesting. I didn’t know I could do that. I’ll go through the tutorial and see if that doesn’t help me figure out what’s going on. Thanks!

[codex653]

Wow ok, somehow I missed that… Whoops.

So I’ve tried flashing to 0x00000000 and the raw binary doesn’t seem to be working after reset. I don’t have the VGDB profiler or stub init functions so I don’t think it’s waiting to connect to the PC. Again, the only way I’ve been able to get the binary to work is that weird method described previously.

• This reply was modified 6 years, 6 months ago by codex653.

[Author]

Posts