Forum Replies Created
-
Posts
-
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…?
Ok, thanks for the info. Our support contract is currently expired and we were going to wait a few months to make sure that our year of support fell within when VS 2022 was released and any VisualGDB updates that had to be made were done but maybe we’ll just update now and hope for the best 🙂
Hey no worries, just glad I could help! Weird certificate/security stuff could very easily be caused by firewalls and anti-virus and that’s the first place I went to look too 🙂
This is actually happening on every computer I’ve tried that’s running Visual Studios 2012 (right now that’s 4) and a 5th computer that is running Visual Studios 2017. Tonight I can install 2012 on my home computer and test it there. That has a very fresh windows install (2 months old) so shouldn’t have anything else interfering.
I’m assuming integration testing is done before releases. If that is the case, then this definitely would have passed, as that would have occurred back before the 5.4R12 release in July of 2019 and this broke only within the last few months. I’m curious if the same tests would pass now (using that code, not the 5.5 preview code).
So, I’ve determined that this is not a firewall problem, as my laptop fails both at home and at work. I believe it has to do with what Windows decides to use as the default level of Tls encryption for .Net applications that do not specifically specify it.
Using the initial provided C# code, my work laptop fails to connect and throws the cannot create socket error. Using Fiddler, I can see that it’s making the connection request using Tls 1.0. I tested my laptop on my home network and got the same results. I tested my brand new home computer, and it worked, creating the Tls connection at 1.2. I tested my older home computer and it failed, creating the Tls connection at 1.0. All three machines are running Windows 10, version 1909 but only my new home computer is a fresh 1909 install, the others were upgrades from prior versions.
However, I’m not certain that the Windows information is completely relevant (though it might be, so I included it). My laptop failed to make the connection when I created the project using Visual Studios 2012, which is what we use as our primary development platform. I do however have Visual Studios 2019 installed (which is what my new home computer uses), so I decided create a project in that. Using the exact same code, it succeeds. I then checked if VisualGDB->Manage Packages works correct in VS2019, and it does. My old home computer is running Visual Studios 2017 and that fails.
So, here’s what I think:
VisualGDB’s website was updated to require Tls 1.2 connections somewhat recently.
VisualGDB’s connection string does not specify a level of Tls.
If a Tls level is not provided by the application, Visual Studios will use a default level. Older versions (VS2012 and VS2017) default to 1.0, which will fail. VS2019 uses 1.2 and will thus succeed.If I am correct, then everyone using an older version of Visual Studios should be encountering this problem. Fortunately we have a work around such that we can install VS2019 and update packages that way. Since they store the information in the VisualGDB folder, older versions of VS will see the updated package information as well. Future versions of VisualGDB should probably enforce a minimum tls level on their connection strings, so this will resolve the issue for people using older versions of VS without having to do any work around (again, this is assuming that my above assumptions are correct).
Ok, I still don’t know exactly where the issue lies, because while it could be a firewall issue it could also be a Windows Update issue causing older version of security protocols to become obsolete. I suppose it could even be a back-end update on your website that would break older versions of VisualGDB, but I suspect there would be a lot more complaints on the forums if that were the case.
This code fails:
WebClient webClient = new WebClient();
string sData = webClient.DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");This code succeeds:
WebClient webClient = new WebClient();
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
sData = webClient.DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");Tls12 is only available starting in .Net framework 4.5 (along with Tls11, which I also tried and it failed). 3.5 and 4 only have Tls available.
