Let’s see if I can get someone to release info about OWL3 pin mapping. It’s not supposed to be a secret as it was done for OWL1 and Xibeca, most likely it never happened because it was a low priority thing.
Regarding that buttons problem, you should try to make a debug build (by setting CONFIG=Debug environment variable when build) and see what happens when you press them. There are 2 possibilities:
1.Try to pause and see what happens before firmware resets on button press. If impossible, you would have to place a breakpoint, most likely in EXTI interrupt handler or code that updates buttons
- It might be some unhandled interrupt (EXTI most likely), then you would end up in the default interrupt that also happens to be an infinite loop. It’s implemented in assembly in startup file, so you will notice that you’re not running normal OWL code.
To run this in gdb you have 2 choices:
- Keep the bootloader, send the debug build via sysex and expose its symbols. You will actually flash bootloader rather then firmware and this can be a bit glitchy, but allows you to run with unmodified linker scripts.
Something like this should be added in case of vscode:
"postLaunchCommands": [
"monitor arm semihosting enable",
"add-symbol-file Magus3/Build/Witch3.elf 0x080202c0"
]
Address must be pointing to the beginning of your .text section and it might be a bit different, so check ELF file details to confirm. And yes, you will need semihosting to be enabled for running debug builds and you can use printf() for logging if you wish so.
-
https://github.com/RebelTechnology/OpenWare/blob/master/Hardware/owl3.ld#L27 - change origin to be 0x08000000 here. Then you will be flashing firmware directly, without installing bootloader at all. I think this approach works too, also a few uncommon functions would end up broken. I.e. we store some metadata in the end of bootloader - things like protection bits for flashing firmware via sysex and some other metadata. But it probably won’t be a problem for debugging this issue as this is used as response to requests send over MIDI.
-
You might be able to configure openocd to flash to 0x08020000 and it would catch up once you exit bootloader. Never tried this myself, but it seems like it would be a good approach if it actually works.
Using vscode + cortex-debug plugin is highly recommend, here’s what I have in vscode config for another project:
{
"type": "cortex-debug",
"request": "launch",
"servertype": "openocd",
"cwd": "${workspaceRoot}",
"executable": "MidiBoot3/Build/MidiBoot-Magus.elf",
"name": "Midiboot3 Magus3 boot",
"device": "STM32H743ZGT",
"svdFile": "/home/antisvin/.platformio/platforms/ststm32/misc/svd/STM32H7x3.svd",
"armToolchainPath": "/home/antisvin/gcc-arm-none-eabi-10.3-2021.10/bin/",
"gdbPath": "/home/antisvin/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gdb",
"configFiles": [
"Hardware/openocd_h7.cfg"
],
"runToMain": true,
"postLaunchCommands": [
"monitor arm semihosting enable",
"add-symbol-file Magus3/Build/Magus3.elf 0x080202c0"
]
}
Setting svdFile might not be necessary, also toolchain/gdb paths might not be necessary if you install ARM-GCC globally.
