Forum Replies Created
-
Posts
-
Yup, and VisualGDB is great 🙂
After testing with the Segger… it would appear that the RAMcode they use for loading external flash isn’t quite right for the current release of the H757 eval board. There were previous revisions of this board and I’m not sure if the timings on the flash chip changed, but Segger fails to program it with the correct values. Sigh
What external memory looks like when programmed via OpenOCD (with my flash driver) or CubeProgrammer
0x0 0x230057ff 0x5d035aff 0xea045aff
0xd60559ff 0xa70559ff 0x490357ff 0x170059ffWhat Segger creates
0xff00ff00 0xff00ff00 0xff57ffff 0xff5affff
0xff5dff03 0xff5bffff 0xffa9ff05 0xff5affffSeems like it’s only writing 16 bits to each 32 bit spot. Well, off to the Segger forums I go…
Thanks for the help!
Yea, I might have to look into using the Segger J-Link. We’ve used OpenOCD and ST-Links on all of our products up this point but this is the first time we’ve tried to use either external flash or a dual core processor, so hitting some growing pains. We have a few J-Links in house and there does appear to be a JTAG port on the H7 Eval board (which is the only thing we have at the moment) so I’m going to try that. It’s too bad those things are like 10x the price of ST-Links….
I’m giving up for the time being on figuring out why it can’t read memory. I can debug and it does program external flash, so I can deal with it for now.
I did all the development work using OpenOCD as that was what was in the tutorial. However, this is a Dual Core part so ideally I’d be using the ST Fork of OpenOCD. Doing so… does not work great. Or at all really. Would you expect the QSpiDriver to work with both OpenOCD and the ST Fork?
mon report_flash_progress 1
&"mon report_flash_progress 1\n"
@"Device: STM32H74x/75x\n"
@"flash size probed value 2048k\n"
@"STM32H7 flash has dual banks\n"
@"Bank (0) size is 1024 kb, base address is 0x08000000\n"
@"Device: STM32H74x/75x\n"
@"flash size probed value 2048k\n"
@"STM32H7 flash has dual banks\n"
@"Bank (1) size is 1024 kb, base address is 0x08100000\n"
@"Device: STM32H74x/75x\n"
@"STM32H757XIXx.cm4 cannot read the flash size register\n"
@"assuming 2048k flash\n"
@"STM32H7 flash has dual banks\n"
@"Bank (2) size is 1024 kb, base address is 0x08000000\n"
@"Device: STM32H74x/75x\n"
@"STM32H757XIXx.cm4 cannot read the flash size register\n"
@"assuming 2048k flash\n"
@"STM32H7 flash has dual banks\n"
@"Bank (3) size is 1024 kb, base address is 0x08100000\n"
@"Failed to read memory at 0x00003000\n"
@"Failed to read memory at 0x00003000\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
&"Remote communication error. Target disconnected.: Not a directory.\n"
^error,msg="Remote communication error. Target disconnected.: Not a directory."
load
&"load\n"
&"You can't do that when your target is `exec'\n"</code>
<code>^error,msg="You can't do that when your target is `exec'"Ok, so pretty sure it comes down to the fact that it can’t read the values at the QSPI flash address even though it can write there.
x/20xw 0x90000000
&"x/20xw 0x90000000\n"
~"0x90000000 <_ZL14_acarrow_right>:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
~"0x90000010:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
~"0x90000020:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
^done
(gdb)Using the CubeProgrammer I can look at the values at
0x90000000and they are not 0. I can even print them out to a UART in my code, so I know that my code is capable of reading the memory. OpenOCD is using some very low level driver read functions to try and read memory that I can’t quite figure out, so I don’t know why it’s not working.Another thing I can’t figure out that I’m hoping you might be able to tell me… how exactly does the QspiFlash.elf file I made work? I’ve read the address in RAM that it should be loaded at and it never changes. Does OpenOCD actually load it onto the processor at any point, or does it just use the Elf file and like, execute it’s assembly code directly on the target cpu or something? It’s obviously working as I can write to the external flash, but I can’t figure out how it’s work.
Oh yea, I wouldn’t expect you guys to have a tutorial for every CPU. That would be just, an absurd amount of work that never ended. The example got me 98% of the way there, I just had to make some tweaks to get it running for the H7 eval board. There was always the off chance someone would post “oh yea, don’t forget to do XYZ on the H7, it’s different!”. For example, enabling the CRC peripheral. Which might be a thing you have to do… unclear.
As far as I can tell, the “compare-sections” command doesn’t utilize any of the functions in FLASHPlugin.c (I put a breakpoint in all of them). This is the error message that get spit out around the time it fails to read the flash section
Debug: 4317 94061 hla_target.c:278 adapter_debug_entry(): entered debug state in core mode: Handler at PC 0x000002de, target->state: halted
Debug: 4318 94068 target.c:1784 target_call_event_callbacks(): target event 17 (debug-halted) for core stm32h7x.cpu0
Debug: 4319 94076 hla_target.c:323 adapter_poll(): halted: PC: 0x000002de
Debug: 4320 94080 armv7m.c:656 armv7m_wait_algorithm(): failed algorithm halted at 0x2de, expected 0x2000002e
Error: 4321 94087 armv7m.c:921 armv7m_checksum_memory(): error executing cortex_m crc algorithm
Debug: 4322 94093 target.c:2111 target_free_working_area_restore(): freed 52 bytes of working area at address 0x20000000
Debug: 4323 94098 target.c:1910 print_wa_layout(): 0x20000000-0x2000ffff (65536 bytes)
Debug: 4324 94102 target.c:2419 target_read_buffer(): reading buffer of 12 byte at 0x90000000
Debug: 4325 94110 hla_target.c:601 adapter_read_memory(): adapter_read_memory 0x90000000 4 3
Debug: 4326 94115 stlink_usb.c:1102 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
Debug: 4327 94120 gdb_server.c:1493 gdb_error(): Reporting -4 to GDB as generic error
Debug: 4328 94126 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $E0E#baWhen I got look at stlink_usb.c, this is the part of the case statement that handles the error code
case STLINK_SWD_AP_FAULT:
/* git://git.ac6.fr/openocd commit 657e3e885b9ee10
* returns ERROR_OK with the comment:
* Change in error status when reading outside RAM.
* This fix allows CDT plugin to visualize memory.
*/
LOG_DEBUG("STLINK_SWD_AP_FAULT");
return ERROR_FAIL;I have yet to try having that just return ERROR_OK yet, still poking at other stuff.
I did notice this error message in there:
Error: 4321 94087 armv7m.c:921 armv7m_checksum_memory(): error executing cortex_m crc algorithm
so I turned on the CRC peripheral in both the QSpiFlashDriver project and my own project, but I still get that error so unclear if it is related or not.These are the commands I’m using to connect to the GDB instance and load/program
arm-none-eabi-gdb.exe --interpreter mi C:\SrcGit\STM32H757Eval\Project\Solution\STM32H757Eval-CM7\Debug\STM32H757Eval-CM7.elf
-list-features
-gdb-set verbose on
-gdb-set filename-display absolute
-gdb-set disassembly-flavor intel
-gdb-set print demangle off
set remotetimeout 60
target remote :3333mon halt
info shared
mon reset init
mon report_flash_progress 1x/20xw 0 // This is just to check that my QSpiDriver is in memoryloadcompare-sectionsI have attached the entire debug output… because why not. I have also attached the call stack for when it hits that
"STLINK_SWD_AP_FAULT"error.Not gonna lie, I was really hoping you’d say something like “oh, for the H7 the example is inaccurate, you also need to do X” 🙂
Looks like I’m in for the long haul… It’s been about half a decade since I last built and debugged OpenOCD, I’m assuming these instructions still accurate? https://visualgdb.com/tutorials/arm/openocd/build/
I’ll post back here when I figure out what’s up (or have more questions), it might help someone else.
Well, I apparently can’t upload .xml files, so here it is
<?xml version="1.0"?> <EmbeddedProfile xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ToolchainID>com.visualgdb.arm-eabi</ToolchainID> <ToolchainVersion> <GCC>10.3.1</GCC> <GDB>10.2.90</GDB> <Revision>1</Revision> </ToolchainVersion> <BspID>com.visualgdb.bsp.in-place</BspID> <BspVersion>1.0</BspVersion> <McuID>STM32L486QC</McuID> <MCUDefinitionFile>stm32l486xx.xml</MCUDefinitionFile> <MCUProperties> <Entries /> </MCUProperties> <BSPSourceFolderName>Device-specific files</BSPSourceFolderName> <InPlaceMCU> <ID>STM32L486QC</ID> <UserFriendlyName>STM32L486QC</UserFriendlyName> <CompilationFlags> <PreprocessorMacros> <string>SYS_NAME=$(SYS_NAME)</string> <string>RUNNING_FREE_RTOS</string> <string>USE_CUBEMX_USB</string> <string>STM32L486QC</string> <string>STM32L486xx</string> <string>ARM_MATH_CM4</string> <string>__CORTEX_M4__</string> <string>REV3</string> </PreprocessorMacros> <IncludeDirectories> <string>../../../STM32_FrameworksL4/Drivers/CMSIS/Device/ST/STM32L4xx/Include</string> <string>../../../STM32_FrameworksL4/Drivers/STM32L4xx_HAL_Driver/Inc</string> <string>../../../STM32_FrameworksL4/Drivers/STM32L4xx_HAL_Driver/Inc/Legacy</string> <string>../../../STM32_FrameworksL4/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2</string> <string>../../../STM32_FrameworksL4/Middlewares/Third_Party/FreeRTOS/Source/include</string> <string>../../../STM32_FrameworksL4/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1</string> <string>../../../STM32_FrameworksL4/Middlewares/ST/STM32_USB_Device_Library/Core/Inc</string> <string>../../../STM32_FrameworksL4/Drivers/CMSIS/Include</string> <string>../../../CryptoV3.1.3/AccHw_Crypto/STM32L4/Middlewares/ST/STM32_Crypto/Inc</string> <string>../../../PtxComps</string> <string>../../../PtxComps/Services</string> <string>../../../PtxComps/ControlComps</string> <string>../../../PtxComps/Utils</string> <string>../../../PtxComps/HwComps</string> <string>../../../PtxComps/HwDrivers</string> <string>../../../PtxComps/Tasks</string> <string>../../../PtxComps/Init</string> <string>../../../PtxComps/ThirdParty/include</string> <string>../../../PtxComps/ThirdParty/littlefs-2.4.2</string> <string>../../../PtxComps/Utils</string> <string>../../../PtxComps/USB</string> <string>../../../PtxComps/USB/Composite</string> <string>../../../PtxComps/USB/RNDIS</string> <string>../../../PtxComps/Utils/Crypto</string> <string>../../CubeMXRev3/Inc</string> <string>../../Code</string> </IncludeDirectories> <CFLAGS>-Wall -Wextra -Wno-unknown-pragmas -Wno-unused-parameter -ffunction-sections -fdata-sections</CFLAGS> <CXXFLAGS>-Wall -Wextra -Wno-unknown-pragmas -Wno-unused-parameter -ffunction-sections -fdata-sections</CXXFLAGS> <LDFLAGS>--specs=nano.specs --specs=nosys.specs</LDFLAGS> <ASFLAGS>-Wall -Wextra -Wno-unknown-pragmas -Wno-unused-parameter -ffunction-sections -fdata-sections</ASFLAGS> <LinkerScript>../../CubeMXRev3/STM32L486QGIx_FLASH_APP.ld</LinkerScript> <COMMONFLAGS>-mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard</COMMONFLAGS> <EnableLinkerGroups>true</EnableLinkerGroups> </CompilationFlags> <AdditionalSourceFiles /> <AdditionalHeaderFiles /> <MemoryMap> <Memories> <MCUMemory> <Name>FLASH</Name> <Address>134217728</Address> <Size>1048576</Size> <AddressSpaceSize>0</AddressSpaceSize> <Flags>IsDefaultFLASH</Flags> </MCUMemory> <MCUMemory> <Name>RAM</Name> <Address>536870912</Address> <Size>98304</Size> <AddressSpaceSize>0</AddressSpaceSize> <Flags>None</Flags> </MCUMemory> <MCUMemory> <Name>RAM2</Name> <Address>268435456</Address> <Size>32768</Size> <AddressSpaceSize>0</AddressSpaceSize> <Flags>None</Flags> </MCUMemory> </Memories> </MemoryMap> <AdditionalSystemVars> <SysVarEntry> <Key>com.sysprogs.bspoptions.arm.core</Key> <Value>M4</Value> </SysVarEntry> <SysVarEntry> <Key>com.sysprogs.stm32.hal_header_prefix</Key> <Value>stm32l4xx</Value> </SysVarEntry> <SysVarEntry> <Key>com.sysprogs.bspoptions.stm32.hal_system_file</Key> <Value>STM32L4xxxx/CMSIS_HAL/Device/ST/STM32L4xx/Source/Templates/system_stm32l4xx.c</Value> </SysVarEntry> <SysVarEntry> <Key>com.sysprogs.bspoptions.stm32.hal_config_template_file</Key> <Value>STM32L4xxxx/STM32L4xx_HAL_Driver/Inc/STM32L4xx_hal_conf_template.h</Value> </SysVarEntry> <SysVarEntry> <Key>com.sysprogs.stm32.hal_device_family</Key> <Value>STM32L486xx</Value> </SysVarEntry> </AdditionalSystemVars> <ConfigurableProperties> <PropertyGroups> <PropertyGroup> <Properties> <PropertyEntry xsi:type="Enumerated"> <Name>Execute from</Name> <UniqueID>com.sysprogs.bspoptions.primary_memory</UniqueID> <OmitPrefixIfEmpty>false</OmitPrefixIfEmpty> <SuggestionList> <Suggestion> <UserFriendlyName>FLASH</UserFriendlyName> <InternalValue>flash</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>SRAM</UserFriendlyName> <InternalValue>sram</InternalValue> </Suggestion> </SuggestionList> <DefaultEntryIndex>0</DefaultEntryIndex> <AllowFreeEntry>false</AllowFreeEntry> </PropertyEntry> <PropertyEntry xsi:type="Enumerated"> <Name>Floating point support</Name> <UniqueID>com.sysprogs.bspoptions.arm.floatmode</UniqueID> <OmitPrefixIfEmpty>false</OmitPrefixIfEmpty> <SuggestionList> <Suggestion> <UserFriendlyName>Software</UserFriendlyName> <InternalValue>-mfloat-abi=soft</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>Hardware</UserFriendlyName> <InternalValue>-mfloat-abi=hard</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>Unspecified</UserFriendlyName> <InternalValue /> </Suggestion> </SuggestionList> <DefaultEntryIndex>0</DefaultEntryIndex> <AllowFreeEntry>false</AllowFreeEntry> </PropertyEntry> <PropertyEntry xsi:type="Boolean"> <Name>Exclude the startup file from project</Name> <UniqueID>com.sysprogs.mcuoptions.ignore_startup_file</UniqueID> <OmitPrefixIfEmpty>false</OmitPrefixIfEmpty> <DefaultValue>false</DefaultValue> <ValueForTrue>1</ValueForTrue> </PropertyEntry> <PropertyEntry xsi:type="Enumerated"> <Name>C Library Type</Name> <UniqueID>com.sysprogs.toolchainoptions.arm.libctype</UniqueID> <OmitPrefixIfEmpty>false</OmitPrefixIfEmpty> <SuggestionList> <Suggestion> <UserFriendlyName>Default</UserFriendlyName> <InternalValue /> </Suggestion> <Suggestion> <UserFriendlyName>Newlib-nano</UserFriendlyName> <InternalValue>--specs=nano.specs</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>Newlib-nano with floating point support in printf()</UserFriendlyName> <InternalValue>--specs=nano.specs -u _printf_float</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>Newlib-nano with floating point support in printf() and scanf()</UserFriendlyName> <InternalValue>--specs=nano.specs -u _printf_float -u _scanf_float</InternalValue> </Suggestion> </SuggestionList> <DefaultEntryIndex>1</DefaultEntryIndex> <AllowFreeEntry>false</AllowFreeEntry> </PropertyEntry> <PropertyEntry xsi:type="Enumerated"> <Name>Implementations for _sbrk(), etc.</Name> <UniqueID>com.sysprogs.toolchainoptions.arm.libnosys</UniqueID> <OmitPrefixIfEmpty>false</OmitPrefixIfEmpty> <SuggestionList> <Suggestion> <UserFriendlyName>None</UserFriendlyName> <InternalValue /> </Suggestion> <Suggestion> <UserFriendlyName>Minimal (no semihosting)</UserFriendlyName> <InternalValue>--specs=nosys.specs</InternalValue> </Suggestion> <Suggestion> <UserFriendlyName>Support semihosting</UserFriendlyName> <InternalValue>--specs=rdimon.specs</InternalValue> </Suggestion> </SuggestionList> <DefaultEntryIndex>1</DefaultEntryIndex> <AllowFreeEntry>false</AllowFreeEntry> </PropertyEntry> </Properties> <CollapsedByDefault>false</CollapsedByDefault> </PropertyGroup> </PropertyGroups> </ConfigurableProperties> <HierarchicalPath>STM32\STM32L4</HierarchicalPath> <FamilyID>STM32L4</FamilyID> <FLASHSize>1048576</FLASHSize> <FLASHBase>134217728</FLASHBase> <RAMBase>536870912</RAMBase> <RAMSize>98304</RAMSize> <RAM2Base>268435456</RAM2Base> <RAM2Size>32768</RAM2Size> <MCUDefinitionFile>stm32l486xx.xml</MCUDefinitionFile> <AdditionalSourcesRequiredForTesting>false</AdditionalSourcesRequiredForTesting> </InPlaceMCU> <MCUMakFile>stm32.mak</MCUMakFile> <ReferencedFrameworks /> <FrameworkProperties> <Entries> <KeyValue> <Key>com.sysprogs.bspoptions.stm32.ll_driver</Key> <Value /> </KeyValue> </Entries> </FrameworkProperties> <TestFrameworkProperties> <Entries /> </TestFrameworkProperties> </EmbeddedProfile>Nevermind, figured it out. Turns out things work better when you modify your path so that things from 2007 aren’t before more recent installs (also adding the \bin folder for those recent installs to the path..)
Yup, I was indeed building the MultiCore platform, didn’t even notice that there were multiple ones to choose from. Switching to Mainstream threw an error in the same spot, so I did a fresh clone and it now builds *almost* everything. I’m not entire sure what it’s attempting to do so I’m not sure where to go to try and fix it.
[1/6] Generating startup.tcl
FAILED: src/startup.tcl
cmd.exe /C “cd /D C:\Src\OpenOCD\OpenOCD3\build\Mainstream\Debug\src && C:\Src\OpenOCD\OpenOCD3\external\run-sh.bat -c “cat C:/Src/OpenOCD/OpenOCD3/src/helper/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/jtag/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/target/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/flash/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/server/startup.tcl > C:/Src/OpenOCD/OpenOCD3/build/Mainstream/Debug/src/startup.tcl””C:\Src\OpenOCD\OpenOCD3\build\Mainstream\Debug\src>set PATH=c:\sysgcc\mingw32\bin;c:\sysgcc\mingw32\bin;C:\WinAVR-20070525\bin;C:\WinAVR-20070525\utils\bin;c:\Visual\RunTime70;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\WinAVR-20100110\bin;C:\WinAVR-20100110\utils\bin;C:\Program Files (x86)\Atmel\AVR Tools\AVR32 Toolchain\bin;C:\Visual\RunTime70\Axis2c\lib;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\dotnet\;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility;C:\Program Files (x86)\Mitel\Connect\;C:\Program Files\TortoiseGit\bin;C:\Program Files\Git\cmd;C:\Users\jkazmierczak\AppData\Local\Microsoft\WindowsApps;C:\Program Files (x86)\Nmap;;C:\Program Files\Git\bin
C:\WinAVR-20070525\utils\bin\sh.exe
C:\WinAVR-20100110\utils\bin\sh.exe
C:\Program Files\Git\bin\sh.exeC:\Src\OpenOCD\OpenOCD3\build\Mainstream\Debug\src>sh -c “cat C:/Src/OpenOCD/OpenOCD3/src/helper/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/jtag/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/target/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/flash/startup.tcl C:/Src/OpenOCD/OpenOCD3/src/server/startup.tcl > C:/Src/OpenOCD/OpenOCD3/build/Mainstream/Debug/src/startup.tcl” -c0
0 [main] sh 27576 sync_with_child: child 30512(0x15C) died before initialization with status code 0xC0000142
14 [main] sh 27576 sync_with_child: *** child state waiting for longjmp
-c0: fork: Resource temporarily unavailable
ninja: build stopped: subcommand failed.
————————————————————-
Command exited with code 1
Executable: C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
Arguments:
Directory: C:\Src\OpenOCD\OpenOCD3\./build/Mainstream/Debug
Command-line action failedI put them up on my google drive.
Broken: https://drive.google.com/file/d/1R3ggILujlAv-eyjpK-MRLWH4d0Ym7lLd/view?usp=sharing
Working: https://drive.google.com/file/d/1oyRoaibynUWN2I1H489s4j3x2tl8G2_0/view?usp=sharing
I’ll check out the beta later today
I’ve attached two projects, one of them works and the other one breaks. I did have to remove the BSP folder from the rar file as it put it over the 500KB limit.
In our real builds, we don’t actually use the BSP folder. When creating it as a stand-alone we remove all references to the BSP files rather than copying them over. We then reference the STM32 frameworks directly. The folder structure is also defined before I start doing anything with files, I just did it this way to try and track down the exact point that it breaks.
Yea, I’d love to move over to using the CMake system but we have a lot of infrastructure built around makefiles as they are. For the time being its a necessary pain but I hope to get free time in the future to upgrade our support tools to support CMake…
Once you take a look at these project files I’ll play around with the 5.6 beta.
Thanks!
Ok, figure out how to break it. Note, I am using VS 2012 and VisualGDB 5.5R5.
I have two copies of the same start up code I generated above. In one of them, the solution and Visual Studios project are in the main folder, and /code and /BSP is underneath it. In the other one, the top level folder has a /BSP, /Code and /Solution folder. That one breaks.
The max upload size is 512KB and the entire folder is about 3MB zipped. If you want I can upload everything except the BSP folder, that should fit.
To reproduce yourself:
Visual Studios -> New Embedded Project
GNU Make -> Advanced settings
STM32H743II
Execute from: Flash
Floating Point: Hardware
Newlib-Nano
Minimal (no semihosting)
LEDBlink (HAL)
GDB path style: Use toolchain defaultAfter project is created:
VisualGDB Properties-> Convert to stand-alone project
– Choose “Copy all BSP files to project directory”
– Remove all “Additional Sources”Apply Changes. Save All and Close Visual Studios.
Go to Windows Explorer.
Browse to project folder and create a new ‘Solution’ folder alongside the BSP folder.
Move VS project and VisualGDB files into new solutions folder.
Create another folder called Code. Move the Test.cpp file there (or whatever you named your project that contains the int main)Open VS project. Remove all existing BSP .c files and re-add them so they get the new, correct path (don’t forget the start_stm32h743xx.c)
Open VisualGDB properties and correct ‘Include directories’ to be relative path instead of an incorrect absolute path
Add the relative path to “..\Code”Now you should be in position to break things! You need to create a header file and modify int main() to call something in it.
int main(void) { HAL_Init(); TestObj* obj = new TestObj(); for (;;) { obj->Inc(); } }This was my header file
#ifndef __TEST_OBJ_H__
#define __TEST_OBJ_H__class TestObj { public: TestObj(); void Inc(); private: int m_nTest; }; #endifThat should cause you to throw an undefined reference error which will throw the Visual Studios error when you click on it. I’d like to note that before I created the /Code folder and the main.cpp was in the same folder as the project, it didn’t break. It was only after I moved the .cpp into the separate /code folder that things break.
After I got this in a broken state, I opened the solution using Visual Studios 2019, which did NOT have VisualGDB installed for it. While the normal output window isn’t quite as advanced, it basically did what was expected and didn’t throw any errors. I then installed VisualGDB for VS2019 and used the VisualGDB output window and it broke.
OK well, it didn’t upload because XML files aren’t allowed, so here’s what I believe to be the relevant entry:
<entry> <record>387</record> <time>2021/08/17 22:07:25.568</time> <type>Error</type> <source>Editor or Editor Extension</source> <description>System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Code\FirestormBootTask.cpp'. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.File.InternalReadAllBytes(String path, Boolean checkHost) at k02.o2(String a) at cf1.f6(String a) at cf1.p4(hp1 a) at pp2..ctor(IVsTextLines a, al1 d, g13 c, g b) at al1.w(IVsTextLines a, Boolean b) at al1.GetColorizer(IVsTextLines a) at Microsoft.VisualStudio.Package.LanguageService.GetColorizer(IVsTextLines buffer, IVsColorizer& result) at Microsoft.VisualStudio.Editor.Implementation.LanguageServiceClassificationTagger.TryCreateTagger(ITextBuffer textBuffer, IVsFontsAndColorsInformationService fontAndColorInformation, Int32 longBufferLineThreshold, LanguageServiceClassificationTagger& classifier) at Microsoft.VisualStudio.Editor.Implementation.LanguageServiceClassificationTaggerProvider.CreateTagger[T](ITextBuffer buffer) at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.GatherTaggers(ITextBuffer textBuffer)</description> </entry>
So this was a new project that I started from scratch. My VisualGDB Path mappings are empty, so not really sure what I’m supposed to be resetting. I’ve never used them before.
While writing out this email and running various tests I have concluded that the depth of “../” doesn’t matter. I have also concluded that this is happening on our legacy projects, I just didn’t notice it because the most likely way to trigger it is to forget to include a file and trigger an undefined reference error. Since all the legacy projects are already set up, I wasn’t seeing the issue, but as I was loading our various framework files into the new solutions I would inevitable miss one and trigger this error.
When opening a fresh instance of Visual Studios and hitting this error for the first time, Visual Studios pops up with an error saying “An exception has been encountered. This may be caused by an extension.”. It then directs me to the activity log, which I have included.
In the log file I’ve included, you can see at the very end that it’s trying to find “FirestormBootTask.cpp” but it’s looking under C:\Program Files rather than the project root…?
