Forum Replies Created
-
AuthorPosts
-
smadeuxParticipant
I didn’t exactly solve the problem of OpenOCD not working, but I did find a workaround and I wanted to share it in case it’s helpful to anyone.
I ended up adding a post-build Python script that is set to flash the microcontroller after it’s done building (VisualGDB Project Properties>Custom build steps).
For STM32 you can easily use the STM32Programmer command line interface. Then under the VisualGDB Debug settings just switch Program FLASH memory to Never.
smadeuxParticipantHey, thanks for the response.
I guess one thing that I forgot to mention is that I have already tried it with a Segger J-Link. It’s been a bit since then so I can’t quite remember what the errors were, but I can give it another shot. On that note, one my coworkers had told me that the J-Link doesn’t work with the STM32H743II. I don’t know if that’s correct or not though.
I’ve also already tried using the ST fork of OpenOCD, but with similar results.
As for STM32CubeIDE, the project I’m working on is one that I’m trying to port from the IAR Arm compiler to gcc-arm-none-eabi with VisualGDB. As far as I know, I can’t easily debug with STM32CubeIDE, but I’d love to know if there is a way.
I’ll take a look on the OpenOCD forum as well to see if there’s anything similar out there.
smadeuxParticipantI managed to figure out the problem. I turns out that the parts of the hex file that are filled with 0x4770BEFF are not actually junk like I thought they were. They’re actually just the default interrupt handlers. My program was hitting some of the handlers and I hadn’t added any thing to tell it where the real handlers were. The solution was just to add the handler names with ‘extern “C”‘ at the top of the file so that the program knew not to use the default interrupt handlers.
smadeuxParticipantI took a look at the log file and the reset command is definately present. Here is a snippet of the log file from when I hit the Reset Embedded Device button:
[ 55499 ms] ~"Reading in symbols for C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s...\n"
[ 55500 ms] ~"\nProgram"
[ 55500 ms] ~" received signal SIGINT, Interrupt.\n"
[ 55512 ms] ~"CPU_SR_Restore () at C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s:113\n"
[ 55512 ms] ~"113\t MSR PRIMASK, R0\n"
[ 55512 ms] *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x08060200",func="CPU_SR_Restore",args=[],file="C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s",fullname="C:\\projects\\HMI17\\Source\\RTOS\\Core\\Micrium\\ucCPU\\Port\\cpu_a.s",line="113",arch="armv7e-m"},thread-id="1",stopped-threads="all"
[ 55512 ms] mon reset init
[ 55513 ms] ~"Current language: auto\n"
[ 55513 ms] ~"The current source language is \"auto; currently asm\".\n"
[ 55533 ms] &"mon reset init\n"
[ 55535 ms] @"Unable to match requested speed 2000 kHz, using 1000 kHz\n"
[ 55536 ms] @"Unable to match requested speed 2000 kHz, using 1000 kHz\n"
[ 55566 ms] @"target halted due to debug-request, current mode: Thread \n"
[ 55566 ms] @"xPSR: 0x01000000 pc: 0x08001ca0 msp: 0x10000200\n"
[ 55583 ms] ^done
[ 55583 ms] x/4xb 0x8060200
[ 55583 ms] &"x/4xb 0x8060200\n"
[ 55595 ms] ~"0x8060200 :\t0x80\t0xf3\t0x10\t0x88\n"
[ 55595 ms] ^done
[ 55595 ms] -exec-continue
[ 55609 ms] ^running
[ 55609 ms] *running,thread-id="all"
I also tried running the “mon reset init” command manually and the same thing as before happened. I’ve attached a screenshot below as well as a screenshot of my Debug Settings.
Attachments:
You must be logged in to view attached files. -
AuthorPosts