Forum Replies Created
-
AuthorPosts
-
MrZANEParticipant
Yeha, their github page doesn’t contain anything useful.
Why do you need the source code?
The binary and all relevant support files can be had from C:\ST\STM32CubeIDE_1.16.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.400.202404281720 if last version of STM32CubeMxIDE is installed.
License issues?MrZANEParticipantRegarding using J-link on the STM32H723ZG nucleo board:
Many of STs STM32 dev. boards can have their STLink debugger CPU reprogrammed with j-link firmware.
This is supported by segger:
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
Don’t know if your specific board is supported, but it might be worth checking out
February 24, 2022 at 01:49 in reply to: Probable bug in Zephyr builds when using overlay files #32310MrZANEParticipantHi,
The new build you linked to solved the problem.
Thanks
February 22, 2022 at 08:58 in reply to: Probable bug in Zephyr builds when using overlay files #32293MrZANEParticipantBelow is the output of the dump bat file.
I notice that the overlay part in the last line doesn’t have quotations ” and path separators are the windows ones \ instead of of unix ones /
If I edit the bat file to fix this the bat files works.So it seems the file path for the overlay file generated by visualGDB isn’t converted to unix style
Hope this helps.
REM Run "C:\Users\JimmyPedersen\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DBOARD=nrf52840dk_nrf52840 -DDTC_OVERLAY_FILE=C:\Users\JimmyPedersen\source\repos\Zephyr-Overlaytest\Zephyr-Overlaytest\Zephyr-Overlaytest.overlay" in directory "C:\Users\JimmyPedersen\source\repos\Zephyr-Overlaytest\Zephyr-Overlaytest/build/nrf52840dk_nrf52840/Debug" on local computer
cd /d C:\Users\JimmyPedersen\source\repos\Zephyr-Overlaytest\Zephyr-Overlaytest/build/nrf52840dk_nrf52840/Debug
set LANG=en_US.UTF-8
set PATH=C:\Users\JimmyPedersen\AppData\Local\VisualGDB\CMake\bin;C:\NRFConnectSDK\v1.8.0\python-env\Scripts;c:\sysgcc\arm-eabi\bin;%PATH%;C:\NRFConnectSDK\v1.8.0\python-env;C:\Users\JimmyPedersen\AppData\Local\VisualGDB\gperf;C:\Program Files (x86)\Sysprogs\VisualGDB
set ZEPHYR_BASE=C:\NRFConnectSDK\v1.8.0\zephyr
set ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
set GNUARMEMB_TOOLCHAIN_PATH=c:/sysgcc/arm-eabi
"C:\Users\JimmyPedersen\AppData\Local\VisualGDB\CMake\bin\cmake.exe" ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DBOARD=nrf52840dk_nrf52840 -DDTC_OVERLAY_FILE=C:\Users\JimmyPedersen\source\repos\Zephyr-Overlaytest\Zephyr-Overlaytest\Zephyr-Overlaytest.overlay
February 22, 2022 at 04:56 in reply to: Probable bug in Zephyr builds when using overlay files #32288MrZANEParticipantAny comment to my last post?
February 17, 2022 at 23:22 in reply to: Probable bug in Zephyr builds when using overlay files #32257MrZANEParticipantHi again,
Like lateralorange said this is related to the path that is generated by visualgdb when configuring the cmake file(s).
I also mentioned this in my original post.Like I said in previous post the only change I made from the the sample project was to add an overlay file in the visualGDB configuration (See attached screenshot).
I’ve also added a screenshots of the VisualGDB build output but this is cropped as the textline is too long.
The complete output from the visualgdb build window is in my first post anywaysI can not follow you instructions regarding dumping the build files since that menu doesn’t seem to be there (See screenshots).
What happens if you set up the bme680 project for the nrf52840dk_nrf52840 and add a overlay file? Does it work for you?
Please do it in the visual studio default path C:\Users\<USERNAME>\source\repos\- This reply was modified 2 years, 9 months ago by MrZANE.
Attachments:
You must be logged in to view attached files.February 16, 2022 at 08:28 in reply to: Probable bug in Zephyr builds when using overlay files #32222MrZANEParticipantWhile I can appreciate that you cant review big personal project the files I sent were done just as I described in the post, it’s basically one of the nRFConnect samples (bme680 sample) with an added overlay file.
If you don’t want to use the file fine, but could you please try one of the samples yourself, and just try to add an simple overlay file.
I’ve also added a screenshot as requested.
- This reply was modified 2 years, 9 months ago by MrZANE.
Attachments:
You must be logged in to view attached files.February 16, 2022 at 01:23 in reply to: Probable bug in Zephyr builds when using overlay files #32215MrZANEParticipantHi
I’ve changed jobs since I created the forum profile. I’ve now updated the forum profile to use the email of our up to date license at my new job.
Regarding dumping the configuration and build commands that isn’t possible in the way that’s described in the link. VisualGDB Build window doesn’t have the buttons shown in the guide.
But reproducing the issue is really simple. I just used the nRFConnect wizard and created a project for the nrf52480dk based on the lpUART example and added an overlay which just changed the uart speed.
Everything compiles just fine until the overlay is added then, depending on what directory you have the files in, you get a different Invalid esacpe code message. No other changes to the project were made.I’ve attached the project files of my example ready for easy testing.
Attachments:
You must be logged in to view attached files.MrZANEParticipantHi,
I realize that. The thing is that the output openocd output looks OK (At least the short one, haven’t read through the long output).
I though there might be something wrong with the visualgdb parser thinking there is an error when there isn’t.
Also the openocd is installed with your package-manager so I was thinking/hopping that it should be tested to work with one of the most popular CPU families (STM32).I might be wrong in my assumptions though.
Would be nice if you could just test the latest openocd released in the package-manager with a STM32 CPU to see where the problem is and either fix it if it’s on your side and otherwise add a note in the PM about not working with stm32Kind regards
MrZANEParticipantAny comments/tips on this issue?
MrZANEParticipantForgot to mention VisualGDB version. It’s 5.6 Beta 4, build 4229
MrZANEParticipantHi
There are some very nice improvements in this new version but sadly there is also an annoying bug.
If I add some variables to be graphed while debugging everything works like it should.
If I then stop the debugging session and start it again it says “No graphs available” even though some variables are selected to be graphed.
This used to work before this update.On request while you are working on the Live watch, a way to pan the data while zoomed in.
Either dragging with left mouse-button pressed and maybe also if there is a way to use the mouse’s scroll-wheel with a keyboard modifier If you need to pan a little longer.FYI. Image attached. This is an Arduino project for and STM32L432 CPU with the variables taken from a .c file.
Attachments:
You must be logged in to view attached files.MrZANEParticipantShould this be understood as that there is no grace period (Time that the software works as normal without internet connection) ?
So if I have spotty wifi connection that sometime drops will that immediately throw me out of visual studio or prevent compilation from working?
July 3, 2020 at 04:26 in reply to: GUI bug in VisualGDB build 3700 (And some earlier builds too) #28653MrZANEParticipantThanks, that fixes it.
MrZANEParticipant -
AuthorPosts