Forum Replies Created
-
Posts
-
I’ve attached a screenshot of my Debug setting with Advanced settings showing. I don’t see anything that looks like the “reset_config trst_and_srst srst_nogate connect_assert_srst” line that the tutorial references. I did find the stm32h7x_dual_bank.cfg file the Advanced setting->Command Line refers to in C:\Users\magene\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts\target. That file refers to stm32H7x.cfg file which I found in the same directory. I found the reset_config line in the stm32H7x.cfg file:
# use hardware reset
#
# The STM32H7 does not support connect_assert_srst mode because the AXI is
# unavailable while SRST is asserted, and that is used to access the DBGMCU
# component at 0x5C001000 in the examine-end event handler.
#
# It is possible to access the DBGMCU component at 0xE00E1000 via AP2 instead
# of the default AP0, and that works with SRST asserted; however, nonzero AP
# usage does not work with HLA, so is not done by default. That change could be
# made in a local configuration file if connect_assert_srst mode is needed for
# a specific application and a non-HLA adapter is in use.
reset_config srst_nogateIs that the file and line I should modify to
reset_config trst_and_srst srst_nogate connect_assert_srst
per the tutorial?
Thanks
Thanks, that’s just what I need. I’m trying to build up a solid understanding of the topics you mentioned (and a lot of other topics) and this information will help a lot.
I’m still a little confused about how to use TinyEmbeddedTests with my main embedded C/C++ project. I’ve built a new unit test project per the tutorial and it runs fine. I’ve added that project to the VGDB solution that has the main project I’m working on. I’m trying to get the unit test project to find the header and source files from my main project so I can write unit tests for the functions in the main project without having to copy them into the unit test project. I’ve add the main project folder to the “Additional Include Directories” and the “Additional System Include Directories” in the C/C++ Project Properties of the unit test project. I’ve also added the main project folder to the “Library Search Directories” in the Linker Project properties. However when I #include one of the .hpp files from my main project to my unit test project, VGDB doesn’t automatically find it. VGDB does pop up the window asking if I want to include it and pointing at where it found the header file. I can tell VGDB to add that .hpp file and my project builds. But when I add a call to one of the functions declared in the .hpp file and defined in the .cpp file of the same name in the same folder as the .hpp file, VGDB gives me an undefined reference error which I think means it can’t find the .cpp file with the function I’m calling. Here’s the error:
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: VisualGDB/Debug/TinyEmbeddedTestsTests.o: in function `TestInstance_CPFTestGroup_SuccessfulTest1::run()’:
C:\Users\gene\Documents\CPF\Software\CPF2023Aug15\CPFsom\VGDBProject\TinyEmbeddedTests/TinyEmbeddedTestsTests.cpp:38: undefined reference to `CPFUtils::getField(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned long)’
Build failed: arm-none-eabi-g++.exe exited with code 1
collect2.exe: error: ld returned 1 exit statusHere are some specific questions:
Q1: Is my approach of having a main project and a unit test project an appropriate approach? If not, what is the preferred approach?
Q2: What is the correct way to tell the unit test project where to look for additional header and source files in the main project without having to maintain a separate copy in each project? Do I have to manually “Add existing item” for every .cpp file in my main project into my unit test project? If so, it there a way to automate this process?
Q3: By looking at the .vcxproj file, it looks like adding the top level main project folder to the “Additional Include Directories” all the subdirectories got added also. Is that correct? If so, is it just the way VGDB works that it asks me if I want to include a new #include header file the first time?
Thanks for all the help
I’d still like to figure out how to use CppUTest with my project. As noted above, I can use the Tiny Embedded Test framework quite nicely. Any suggestions about what I need to do differently to use CppUTest will be appreciated. Thanks.
New piece of information: I built a Tiny Embedded test project, I was able to add my CPFUtilities Files and this test ran as expected. The first one passed and the second one failed.
TEST(DemoTestGroup, MyTest) { //this should pass std::string returnField = CPFUtils::getField("field0,field1,field2,field3", ",", 2); STRCMP_EQUAL("field2", returnField.c_str()); //this should fail returnField = CPFUtils::getField("field0,field1,field2,field3", ",", 3); STRCMP_EQUAL("field2", returnField.c_str()); }I did what I think you suggested: I built a new project from scratch, I used the LEDBlink example from the Embedded Project Wizard. It built and ran just fine. I added the existing CPFUtilities.hpp and CPFUtilities.cpp” files to the project and a #include “CPFUtilities.hpp” line and it built and ran fine also. I built a new Basic CppUTest Demo (HAL) project and it built and ran just fine. When I added the CPFUtilities.hpp and .cpp files and the #include “CPFUtilities.hpp” line just like I did for the LEDBlink example project, I got the same errors I attached to the my first post. I tried adding the CPFUtiliities files with the add existing button in the solution explorer and selecting the files in the top level CPF project folder. I also tried copying the CPFUtilities files into the CppUTestTutorial project folder and got the same errors both ways.
My CPFUtilities .hpp file is pretty simple. It only include <string> and <stdint.h>.
The first error “declaration of ‘operator new’ as non-function’ shows up in the “new” file which is “The -*- C++ -*- dynamic memory management header”.
The next error ‘no matching function for call to ‘operator new(const char[73], int)’ shows up in the “MemoryLeakDetectorNewMacros.h” file.
Based on these facts, it doesn’t seem like a simple program that #includes CPFUtilities doesn’t need these additional files but the CppUTest project does. I’m just guessing but it seems like the CppUTestTutorial doesn’t know where to look for some missing header files.
I’m not sure what’s happening here. Is the attachment in your post supposed to be what you get when you open the attachment in my last post? When I look at my last post, I can see a thumbnail of the attachment and the thumbnail looks right. When I click on the thumbnail, I get a full size image and it’s right also. But the thumbnail and the full size image in your post are both different than mine. I’ve attached what should be the correct image again to this post.
Unfortunately, I’m still have problems. When I opened VGDB today, it wanted to update a few modules. Based on the activity in this thread, this seemed like a good idea. It found, downloaded and installed all the new modules and I was working for a while. Then I closed VGBD and reopened it later in the day working on the same project. It told me it couldn’t find the STM32 Devices Module 2023.08 and asked if I wanted to use 2023.07. I thought when I was watching the update, it did install 2023.08. When I look at my “Manage VisualGDB Packages” menu it does seem to say I only have 2023.07 installed. But it does show I have 2 copies of STM32 Devices. I’ve tried downloading a fresh copy of VGDB but still wound up with 2 copies of 2023.07 (see attached screen shot). If I should have 2023.08, how do I download it? And should I delete one of the 2 copies of STM32 Devices?
An unrelated question: I’d like to download an earlier version of VGDB to see if my red squiggly error line (see my original post) goes away. But the next latest version on your downloads page is dated 2021-03-05. Is that the most recent version before the current latest version?
One piece of good news is the junk characters I was seeing in my ARM Semihosting Console seems to have resolved itself. I cleaned up some recent code and the problem went away. I was probably overwriting an array or buffer somewhere that was stepping on the semihosting memory.
Thank you, that’s what I need to move forward. If you’re interested, my goal with importing the CubeIDE project is to have a new project with copies of all the files in the original CubeIDE project. That way I can rearrange the files and subroutines in a way that makes sense to me. For example, I really don’t like the way CubeIDE puts all the critical DMA, UART, I2C and associated IRQ Handlers in various STM32XXX files. I’d rather have them with the peripheral they’re associated with. And I’d like to put the various peripheral initializations functions in other files also. This way when I do have to regenerate the CubeIDE project, it won’t affect my VGDB project. I’ll just copy and paste the new CubeIDE code into the VDGB project. If this makes sense, it might make be worth having a check box option when import an existing project that is something like “Duplicate existing project in new folder”
I sure wish I’d thought of that before I posted my question. My project built but didn’t run in CubeIDE either. I had mistakenly clicked the “Set all pins as analog (to optimize the power consumption)” option. Clearly, some pin was being configured under the hood as analog that should not have been. I’ve been able to import my simple CubeIDE with low level drivers project into VGDB as a MSBuild project and as an Advances CMake project and blink an LED.
The short term goal is to make sure I can read a UART with DMA, write to a uSD card with FatFS and add unit tests. The long term goal is to see if I can mock hardware and run unit tests on my Windows development box as described in the VGDB tutorials.
Thanks for the help
Thanks for the quick response. I’ve been using VGDB quite happily for a couple of years now but almost entirely with MSBuild projects that I start from scratch or from the ST examples provided in VGDB or the excellent VGDB tutorials. That works great. Now that I’m moving outside my experience base, I’m trying to come up with an efficient work flow. My next attempt will be importing a STM32CubeMX (or STM32CubeIDE) project into a VGDB project that sits in the same folder as the original CubeMX folder so all the necessary files are in the same place. thanks again.
Thanks for the clues, this is almost for sure related to the fact this is a CMake project set up by somebody else. I did build a really simple MSBuild project in VGDB with the same code shown in that snip I attached. It worked just fine with no red error underscores. I think we’re good for now. Thanks again.
