codex653

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 42 total)
  • Author
    Posts
  • in reply to: Multiple Embedded Targets as Platform #28325
    codex653
    Participant

    That’s some fantastic resources! Thank you.

    in reply to: Multiple Embedded Targets as Platform #28249
    codex653
    Participant

    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.

    in reply to: Multiple Embedded Targets as Platform #28224
    codex653
    Participant

    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.

    in reply to: Multi Project Linker Silent Failure #27262
    codex653
    Participant

    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.

    in reply to: Multi Project Linker Silent Failure #27248
    codex653
    Participant

    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! 🙂

    in reply to: Multi Project Linker Silent Failure #27208
    codex653
    Participant

    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?

    in reply to: Multi Project Linker Silent Failure #27204
    codex653
    Participant

    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, 9 months ago by codex653.
    • This reply was modified 4 years, 9 months ago by codex653.
    in reply to: Multi Project Linker Silent Failure #27197
    codex653
    Participant

    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, 9 months ago by codex653.
    Attachments:
    You must be logged in to view attached files.
    in reply to: Multi Project Linker Silent Failure #27191
    codex653
    Participant

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

    in reply to: Formatting engine crash/not responding #24609
    codex653
    Participant

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

    in reply to: Formatting engine crash/not responding #24606
    codex653
    Participant

    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.

    in reply to: VSCode Plugin? #21166
    codex653
    Participant

    That’s a bummer! Thanks for the info.

    in reply to: Code Coverage Reports #21158
    codex653
    Participant

    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.

    in reply to: Binary Flashing the STM32 #20873
    codex653
    Participant

    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!

    in reply to: Binary Flashing the STM32 #20870
    codex653
    Participant

    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.
Viewing 15 posts - 1 through 15 (of 42 total)