Forum Replies Created
-
Posts
-
Good news: I’ve got my app running properly from inside the debugger, after hitting the reset button and after power down/power up. There were 2 problems, one obvious and one not. The obvious problem was I had the “When running without debugger” option in the VisualGDB Project Properties -> Embedded Frameworks -> Fast Semihosting and Embedded Profiler option set to “Wait for debugger to attach”. It should be set to “Ignore profiling/semihosting calls”. Pretty obvious, but it took a while for me to actually catch the error in my app after re-attaching the debugger and examining the call stack. Once I saw the app was hung in some part of the Fast Semihosting calls, I knew where to look.
I was hoping that would be the obvious solution to my problem but there was more. I use CubeMX to set up the clocks and peripherals and then import it into my Visual GDB app. I had my CubeMX project set up to use HAL and LL drivers for different peripherals. As a last resort, I rebuilt the CubeMX project to use only the HAL library. That and the Fast Semihosting option fixed the problem. I didn’t take the time to narrow down the problem to which combination of LL and HAL driver was the issue, I’m just holding my nose and using all HAL drivers.
That’s really good news but now I have to re-write a bunch of working LL code to use the HAL library. Oh well, nobody ever said embedded software development was for sissies.
Thanks for all the help along this painful journey.
@bflannery – That was helpful, I was trying to Debug >> Attach to Process without success. Now that I’m using Debug >> Attach to Running Embedded Firmware like you suggested I can see that the program is stuck at the hard fault handler when it is running from reset or from power up/down. It still runs fine from the VGDB debugger. Now I have to figure out where and what’s causing the hard fault.
I’m still baffled by why it runs fine in the debugger but hard faults otherwise.
I’m back working on this problem and have a new piece of information. My main app was built by importing a .ioc file from CubeMX. This app blinks an LED right after configuring the clock and initializing the GPIO which is my clue that it has started running. It’s this main app that runs fine from the debugger and blinks the LED but I don’t see any blinking LED after reset or after power up (no debugger). I built another app with from the same .ioc file with the same code up to and including blinking the LED but nothing else. It works fine, I can see the LED blinking, from the debugger and after reset and after power up as expected. I’m using the STM32 CubeMonitor-Power debugger and I can see the current change whenever the LED is blinking. When I start the main app from reset or power up, no blinking LED and no change in current. The current just jumps up to the “normal” baseline 7 milliamps and stays there. As if the program doesn’t even start running. Given that my simple startup program works in all conditions, it seems like I’ve got the hardware setup correctly. Could I have done something in my main app to set some register that prevents my app from running outside of the debugger?
Thanks – Gene
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
