parsec67

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 52 total)
  • Author
    Posts
  • in reply to: Problem with syntax coloring #32226
    parsec67
    Participant

    Many thanks, that did the trick!

    Any idea why my license activation was reset?

    parsec67
    Participant

    Happy to report that this solution worked for me too, although I didn’t see any of the error messages that codefrog mentioned. In my case it was a previously uninstalled VS2017 environment that caused the VGDB setup wizard to error out.

    Thanks!

    parsec67
    Participant

    Hi,

    Just installed VS2022 Community yesterday and today I tried installing VisualGDB 5.6 using the downloaded file VisualGDB-5.6-trial.msi. It did not go well.

    In the setup wizard I select “Change”, then untick Visual Studio 2019 since I already have VGDB installed for this version. The setup begins, prompts if  I want to allow it to make changes etc. but then almost instantly quits with the message “ended prematurely”. Please see attached screenshots.

     

    Attachments:
    You must be logged in to view attached files.
    in reply to: VisualGDB large .npa files #31439
    parsec67
    Participant

    I’m interested in knowing how to reduce project folder size as well. My compressed backup files for one of my oldest STM32 projects are 0.5G each. The uncompressed project folder is near 1G, meanwhile a newer project weighs in at only 225 MB.

    I’d like to know which project subfolders can be safely deleted (or excluded from backup) without affecting the ability to later restore the project from a backup.

    in reply to: STM32CubeIDE import question. #28377
    parsec67
    Participant

    Hi,

    Linker script and startup files appears okay now.

    I have uploaded the problematic CubeIDE test project here: https://filebin.net/wjpfj52dull5gmcr

    Thanks

    in reply to: STM32CubeIDE import question. #28296
    parsec67
    Participant

    Update: Scratch my point #5, I got it to debug when importing as MSBuild. On my first attempt with VGDB build 5.5.6.3661 I accidentally had GNU Make set when importing.

    The other 4 points remain and I was able to get the project in working condition by following and fixing each step as outlined above.

     

    in reply to: STM32CubeIDE import question. #28289
    parsec67
    Participant

    PS. Sorry for formatting issues but this editor really blows and I was unable to edit more than twice.

    in reply to: STM32CubeIDE import question. #28286
    parsec67
    Participant

    Hi,

    Still hit a few snags:

    1. CubeIDE project has a startup assembler code ‘startup_stm32f415rgtx.s’ which clashes with VGDB default startup C file:

     

    C:/Users/..../VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F4xxxx/StartupFiles/startup_stm32f415xx.c:955: multiple definition of `Default_Handler';</code>

     

    Excluding startup_stm32f415rgtx.s from the project fixed this issue.

     

    2. Existing CubeIDE linker script was not imported, instead the project defaulted to VisualGDB's linker script. This caused a linker error:

    <code>ld.exe: C:\dev\stm32\VisualGDB\bootmx/../../CubeIDE/Core/Src/main.c:178: undefined reference to `_app_start'

    Also it appears the source hyperlink in the error message evaluates incorrectly. Clicking on it caused an exception:

    VisualGDB version: 5.5.6.3661
    ------------------ vz1 ------------------
    vz1: Failed to open 'c:\sysgcc\arm-eabi\arm-none-eabi\CubeIDE\Core\Src\main.c:178'. ---> System.ArgumentNullException: Value cannot be null.
    Parameter name: textBuffer
    at Microsoft.Requires.NotNull[T](T value, String parameterName)
    at ....

    Creating a local copy of the linker script and modifyng it to match the original fixed this issue.

    3. A few header files were not added to imported project subfolders (filters) where they were supposed to be. Notable here is that the CubeIDE project has .c and .h files bundled in some folders. For instance, FATFS\Target contains ffconf.h, user_diskio.h and user_diskio.c. VGDB splits FATFS\Target into two instances in Solution explorer, ‘Header files’ and ‘Source files’, but only imports user_diskio.c to ‘Source files\FATFS\Target’

    4. One entire project subfolder was not imported (but was listed under Include directories):

    Middlewares\Third_Party\FatFs\src

    This caused a couple of undefined reference linker errors. After I added it manually in Solution Explorer the project finally built with no errors.

    5. I am unable to start a debug session. The solution is not recognized as a VisualGDB project and I only have option Debug->x86 in the VS navigation bar. The project properties shows platform as VisualGDB. Right-clicking on project in Solution explorer and selecting “Debug->Start new session” gives me an error dialog: “Unable to start debugging. Check your debugger settings…”. Settings are good (ST-Link V2) and identical to what I use for other projects.

    Since it may be difficult to follow exactly what is going on based on my explanations only I’d be happy to send you the entire CubeIDE project if you want to try to replicate on your end.

    • This reply was modified 4 years, 4 months ago by parsec67.
    • This reply was modified 4 years, 4 months ago by parsec67.
    in reply to: Program and Start without debugging popup window #25140
    parsec67
    Participant

    I second this request.

    As well, in the case of ESP8266, the option to hide the dialog “The programmed image does not contain the GDB stub. Do you want to open instructions…” .

    in reply to: ESP-IDF custom partition table #24905
    parsec67
    Participant

    Hi,

    As per Espressif documentation, the partition table should be generated automatically during build if configured in sdkconfig and the resulting binary saved in Debug/Release folders.

    Below is just for future reference.

    I created a new blank GNU make project based on hello-world sample, then in VisualGDB/ESP-IDF configuration/Partition table:

    Partition table = Custom partition table CSV
    Custom partition= part2.csv

    part2.csv located in project root folder. This correctly builds part2.bin and puts the binary in the Debug project subfolder.

    I then created a new blank CMake project based on hello-world sample with identical settings in ESP-IDF configuration and part2.csv located in project root directory. The partition table part2.bin is not built, there are no traces of any part2.bin file in the project directory and no references to it or the CSV file in the build output. I tried placing the CSV file in different locations in the file system, providing full path etc. etc. but nothing made a difference.

    With the underlying toolchain being the same there is obviously a discrepancy between GNU make and CMake. Searching Interwebz or looking at Espressif’s GitHub issue tracker was fruitless. So I think I’ll just stick with the slower but working GNU make for now.

    in reply to: STM32F4 GDB break-in request #24101
    parsec67
    Participant

    Definite improvement, thanks. Been debugging the whole day and I see the break-in dialog only occasionally but it always succeeds after a few seconds. I also noticed in my settings that I had programmer set to ST-Link v2.1 which used to work fine but is now reported as deprecated. Perhaps this was related to my problem? At any rate I have switched to ST-Link v2 and it appears to be solid.

    Another thing I noticed is that VStudio loads quickly now compared to before. Just curious if you made some changes to improve startup times?

    in reply to: Importing STM32CubeMX LL project #24078
    parsec67
    Participant

    You have news about this issue, now I try use USART with LL driver but I have many error, I m wrote to ST but I haven’t any reply

    I reported this back in December 2017 (https://bit.ly/2C56WG9). Rather quickly, only 11 months later in November 2018, an ST  employee replied that they would fix this issue in a future CubeMX update. I have not heard anything since so I’m guessing it is not a priority. Given the pace of things I think we can expect a fix in July 2021.

    HAL is crap, it’s just for beginners.

    HAL is what is states to be, hardware abstraction, and it does this job fairly well. I have effortlessly migrated portions of code between F0, F4 and F7 products which would not have been nearly as easy with code based on direct register manipulation. LL kind of improves on full manual low level coding but I found it poorly documented in some cases and it felt less mature at the time. Maybe things have changed now.

    in reply to: STM32 OpenOCD cannot connect to ST Link V2 #22955
    parsec67
    Participant

    I’m using ST-Link V2 and it works great with OpenOCD 0.10.0.

    In the first line of your debug log there is a switch “-f C:/Users/mdric_000/AppData/Local/Temp/tmp62F7.tmp”

    I don’t know if this is significant but comparing to my working setup I have “-f target/stm32f4x.cfg”

    So maybe verify in VisualGDB Project properties/Debug settings window that “Debugged device” is set to your MCU type?

    Also in the Debug settings options, try changing JTAG/SWD debugger option to ST-Link V2.1

    HTH

    parsec67
    Participant

    I don’t have an F7 but…. Did you change the interrupt vector table for your SRAM project? If not then interrupts will not work when booting from SRAM because interrupts — SysTick included — are offset by the start address of SRAM (0x20000000 on F4). The RM for your device should have more info about this.

    in reply to: ESP8266 OTA – user1 and user2 binaries #20536
    parsec67
    Participant

    The “please check the bin file” problem mentioned above turned out to be FileZilla not transferring .bin files in binary mode with auto-detect on so that problem is solved, nothing to do with VGDB and my project is now working satisfactory.

Viewing 15 posts - 1 through 15 (of 52 total)