Activity for Maximilian Gerhardt
-
Maximilian Gerhardt created ticket #3686
Snapshot doesn't run, misses DLLs
-
Many thanks for the comments, indeed I removed the flash references and moved the workspace to end of ram minus 4 kByte (0x200... start was correct though). I struggled quite a bit with then breakpoints properly working in GDB / VSCode+Cortex Debug, but at the end I found out it was trying to use software breakpoints (and failing ofc bc OpenOCD can't flash a break instruction into the flash without a driver), so I had to apply the trick to mark the flash address space as read-only in GDB, and mark...
-
Many thanks for the comments, indeed I removed the flash references and moved the workspace to end of ram minus 4 kByte (0x200... start was correct though). I struggled quite a bit with then breakpoints properly working in GDB / VSCode+Cortex Debug, but at the end I found out it was trying to use software breakpoints (and failing ofc bc OpenOCD can't flash a break instruction into the flash without a driver), so I had to apply the trick to mark the flash address space as read-only in GDB, and mark...
-
Okay I actually have to apologize, I used an old OpenOCD version that was with the distribution, and it did say OpenOCD 0.11.0. But it was from freaking 2021. I grabbed the latest git version, with libjaylink, compiled it mayself, and now the very same configuration file can connect to the chip with no changes! $ ~/ocd/openocd/openocd_installed/usr/local/bin/openocd -f interface/jlink.cfg -c "transport select swd" -s . -f dia.cfg -c "gdb_memory_map disable" Open On-Chip Debugger 0.12.0+dev-01082-gfc30feb51...
-
Okay I actually have to apologize, I used an old OpenOCD version that was with the distribution, and it did say OpenOCD 0.11.0. But it was from freaking 2021. I grabbed the latest git version, with libjaylink, compiled it mayself, and now the very same configuration file can connect to the chip with no changes, ~~reliably~~! $ ~/ocd/openocd/openocd_installed/usr/local/bin/openocd -f interface/jlink.cfg -c "transport select swd" -s . -f dia.cfg -c "gdb_memory_map disable" Open On-Chip Debugger 0.12.0+dev-01082-gfc30feb51...
-
Okay I actually have to apologize, I used an old OpenOCD version that was with the distribution, and it did say OpenOCD 0.11.0. But it was from freaking 2021. I grabbed the latest git version, with libjaylink, compiled it mayself, and now the very same configuration file can connect to the chip with no changes, reliably! $ ~/ocd/openocd/openocd_installed/usr/local/bin/openocd -f interface/jlink.cfg -c "transport select swd" -s . -f dia.cfg -c "gdb_memory_map disable" Open On-Chip Debugger 0.12.0+dev-01082-gfc30feb51...
-
And I guess it would also be a good idea to include the -d4 debug logs of OpenOCD.
-
I've stitched together screenshots from PulseView to give a broad overview here. OpenOCD only gets NOREPLY in the red answer fields, JLinkExe gets NOREPLY, 7xERROR, NOREPLY, then OK. Of course it's best when you look at the traces in PulseView directly though.
-
OpenOCD can't connect to Dialog DA1469x
-
Open per https://review.openocd.org/c/openocd/+/6794 I had another look at the reset watchdog thing, but found there was no watchdog active and the DBG_CTL bits for the watchdogs were set, so I'm not sure what's going on -- hopefully people in review can help with that. I can test on real hardware. EDIT: Corrected superfluous dot in URL.
-
Open per https://review.openocd.org/c/openocd/+/6794 I had another look at the reset watchdog thing, but found there was no watchdog active and the DBG_CTL bits for the watchdogs were set, so I'm not sure what's going on -- hopefully people in review can help with that. I can test on real hardware.
-
Open per https://review.openocd.org/c/openocd/+/6794. I had another look at the reset watchdog thing, but found there was no watchdog active and the DBG_CTL bits for the watchdogs were set, so I'm not sure what's going on -- hopefully people in review can help with that. I can test on real hardware.
-
I've created an OpenOCD fork and added preliminary GD32E50x support in it, in the same style GD32E23x support was added: https://github.com/openocd-org/openocd/compare/master...CommunityGD32Cores:master The patch detects the microcontroller and its flash banks (64 of it per datasheet) correctly, uses the right register addresses for DBG_ID and memory density information, but still has some problems. When the core is halted, the microcontroller seems to reset after some while and the connection is...
-
Support GD32E50x chips
-
This is still not fixed. Getting the exact same error when using https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32/sdcc-snapshot-x86_64-w64-mingw32-20211003-12697.zip/download as my toolchain. Getting Reading symbols from .\.pio\build\debug\firmware.elf...Dwarf Error: Could not find abbrev number 117 in CU at offset 0x0 [in module C:\Users\Max\temp\Blink_PIO_STM8\.pio\build\debug\firmware.elf] in stm8-gdb when using that toolchain in PlatformIO. (Which I do by adding...
-
Thanks, I'll have another shot at reproducing this with the latest released development version, and reupload the pastebin files if necessary / still occurring.
-
I'm still experiencing this issue in the 4.1.0 release on Windows 10 :( (https://github.com/platformio/platform-ststm8/issues/48#issuecomment-806846705)
-
I was just given a good tip in https://github.com/platformio/platform-ststm8/issues/48#issuecomment-806820829 It seems that a perfectly valid SDCC keyword __naked here breaks the build process. Found a similar report here so it indeed seems like a SDCC bug. Refering to https://www.mail-archive.com/sdcc-user@lists.sourceforge.net/msg05982.html, this issue seems to be known.. but not tracked? I've tested it by commenting out __naked in the affected file and compilation of that file works, linking still...
-
Woops, one misplaced formatting option makes the above text a bit hard to read, but I can't edit my tickets to fix it. Needs a moderator?
-
SDCC generates ELF with invalid DWARF info
-
Adding compile_output_debug.zip here because it didn't upload in the first post for some reason.
-
File does not compile with --debug
-
Support for more STM8S targets
-
For installing you need to give it the install directory in the initial ./configure command, like mkdir ~/avarice_installed and ./configure --prefix ~/avarice_installed and then make && make install. But for me, I just grabbed the executable in src/avarice.
-
Support UPDI programming
-
Cannot compile avarice-2.14.tar.bz2 due to '__unused'
-
Thanks, due to all the comments I can now do the equivalent of program {} verify reset. Should this issue be kept open until program works "normally" in openOCD or do we close it? Technically the original question is answered. You decide, since I don't seem to be able to change the status of my ticket in this page somehow..
-
This fixes it. Now I can upload code and verify it with OpenOCD :)
-
This problem also occurs for me in the latest SDCC 4.0 release on Windows 10.
-
Ha, indeed! If I open openOCD with just openocd -f interface\stlink-dap.cfg -f target\stm8s103.cfg and use telnet to connect to localhost:4444 and then do > load_image {C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.bin} 0x8000 2576 bytes written at address 0x00008000 downloaded 2576 bytes in 2.182562s (1.153 KiB/s) > reset It downloads, resets the chip and the LED is blinking. Sadly this doesn't work in a -c command though openocd -f interface\stlink-dap.cfg...
-
Addendunm since I can't apparently update the existing ticket (?). The used chip is a STM8S103F3, connected to an ST-Link V2 clone with the SWIM interface. The target board is powered via USB. The STLink has the latest firmware according to the STM32CubeProgrammer firmware upgrader. Link to board https://www.aliexpress.com/item/32802699526.html (Also ignore the libusb: error it's due to me specifying two adapters, with just stm8flash.exe -c stlinkv21 -p stm8s103?3 -s flash -w "<path to firmware.ihx>"...
-
Addendunm since I can't apparently update the existing ticket (?). The used chip is a STM8S103F3, connected to an ST-Link V2 clone with the SWIM interface. The target board is powered via USB. The STLink has the latest firmware according to the STM32CubeProgrammer firmware upgrader. Link to board https://www.aliexpress.com/item/32802699526.html. (Also ignore the libusb: error it's due to me specifying two adapters, with just stm8flash.exe -c stlinkv21 -p stm8s103?3 -s flash -w "<path to firmware.ihx>"...
-
STM8 program command fails with "invalid subcommand write_image erase.."
1