Change SWD frequency after RCC initialization (STM32+OpenOCD) - Page 1
Forum section: electronics / general

author: Unixon
author_rank: Frequent Contributor
timestamp: May 29, 2021, 04:03:07 pm
content: Is it possible to instruct OpenOCD to read and follow actual MCU frequency, in particular change SWD frequency after RCC initialization for faster debugging?Alternatively, is there a way to pre-configure RCC via OpenOCD even before any debugging starts?

author: ataradov
author_rank: Super Contributor
timestamp: May 29, 2021, 06:27:09 pm
content: SWD frequency should not depend on the core clock unless ST messed something up. Debug Port is a standalone and independent component, which does not need the system clock to work. Access Port would need the bus to be enabled, but it still should handle the slower bus just fine.Have you tried high clock right away? What errors do you get?There would still be some natural limit due to DAP logic itself, but I would expect it to be in the 30+ MHz range.

author: dgtl
author_rank: Regular Contributor
timestamp: May 29, 2021, 06:51:52 pm
content: The openocd configuration files for stm32 do set the adapter frequency depending on the state of the mcu. I don't know, if it has to be so, but it is in the upstream openocd. They have hooked it to reset-start and reset-init events.https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/target/stm32f0x.cfg#l95It is important, that the "reset init" command is used (init argument to reset command), otherwise the reset-init handler is not called and you keep using the very slow speed. Semihosting is almost unusable at that speed, that's why I started investigating and found it out.

author: Unixon
author_rank: Frequent Contributor
timestamp: May 29, 2021, 07:16:07 pm
content: SWD works fine, just not fast enough for me. I'm looking for a way to speed things up.Before RCC is fully initialized the adapter frequency may be only about 1.8MHz max.What I want is to raise SWD clock frequency as soon as system clock is up and running at full speed (72MHz in case of my C-M3) or even better - to write RCC registers from OpenOCD immediately on connection, then wait a little while system clock stabilizes and then kick turbo-SWD mode in.

author: ataradov
author_rank: Super Contributor
timestamp: May 29, 2021, 07:29:13 pm
content: Writing configuration from the debugger is a bit strange, it makes no sense to me, since interferes with the running application. I can see that being useful when just programming and debugger is fully in control. But when actually debugging - what if your application is not ready for the changes made by the debugger, or the opposite - relies on them?

author: Unixon
author_rank: Frequent Contributor
timestamp: May 29, 2021, 07:47:46 pm
content: I need to do this only once while the debug target is halted at reset vector before anything else happens. According to OpenOCD configuration SWD clock is limited by F_CPU/6 and HSI and other clocks are at best 8MHz before RCC is configured. This means that at full speed of 72MHz SWD could be also 9 times faster. Interface latency however will accumulate anyway and this cannot be helped.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 30, 2021, 12:08:10 am
content: Not sure I understand corectly what you want to do, but you should be able to do this. Take a look at OpenOCD's config files for some targets (you'll find them there: share\openocd\scripts\target )For instance, one target that I use is the STM32L4 series. If you take a look at the stm32l4x.cfg file, you'll see that the adapter speed starts at 500 kHz by default ("adapter speed 500") and then switches to 4 MHz on a "reset init" event:Code:$_TARGETNAME configure -event reset-init {# CPU comes out of reset with MSI_ON | MSI_RDY | MSI Range 6 (4 MHz).# Use MSI 24 MHz clock, compliant even with VOS == 2.# 3 WS compliant with VOS == 2 and 24 MHz.mww 0x40022000 0x00000103 ;# FLASH_ACR = PRFTBE | 3(Latency)mww 0x40021000 0x00000099 ;# RCC_CR = MSI_ON | MSIRGSEL | MSI Range 9# Boost JTAG frequencyadapter speed 4000}What that does is that OpenOCD will connect at 500 kHz, but will switch to 4 MHz when you issue a "reset init" command.I'm not sure you can exactly do what you want though - meaning having OpenOCD "read" the actual CPU clock rate and adjust the adapter speed accordingly. You'll need to set the speed as above.I suggest you take a look at various config files, and read OpenOCD's manual.http://www.openocd.org/doc/html/

author: Unixon
author_rank: Frequent Contributor
timestamp: May 30, 2021, 08:59:00 am
content: Quote from: SiliconWizard on May 30, 2021, 12:08:10 amI want to make SWD to always work at maximum possible speed which depends on the actual JTAG/SWD clock of MCU, this means OpenOCD has to somehow read this value from MCU and then set the adapter speed accordingly. Since the frequency value isn't stored anywhere the only way to do this is to read RCC registers and calculate at what frequency JTAG/SWD should be operating.I'm quite disappointed about remote debugging performance of GDB+OpenOCD and the reason it's so slow may be because it takes so much time to talk to MCU at safe speed.I don't know if boosting adapter speed really helps, but I hope that changing it from 1.8MHz to about 12MHz may have some effect on performance.

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2021, 04:36:03 pm
content: What is your debugger hardware? If it is some USB FS device, then performance is likely limited by the USB.Debugging at 1 MHz should not feel to slow unless you are reading out huge memory arrays.

author: Unixon
author_rank: Frequent Contributor
timestamp: May 30, 2021, 08:12:00 pm
content: Quote from: ataradov on May 30, 2021, 04:36:03 pmI'm using "ST-Link V2 ISOL" and AFAIK it's an USB 2.0 device so it can do better.What bothers me is latency appearing at every connection in IDE-GDB-OpenOCD-USB-STLink-STM32 chain, even if I make the last link faster it still may not help that much.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 30, 2021, 08:13:31 pm
content: Quote from: Unixon on May 30, 2021, 08:12:00 pmI'm not sure I understand what you mean. The connection time shouldn't matter much - it should be done only once for a debugging session. How do you use this setup?

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2021, 09:24:56 pm
content: Quote from: Unixon on May 30, 2021, 08:12:00 pmIt is a USB FS device, so 1.2 MBytes/sec is the maximum theoretical transfer, and in reality with request-response you will never get even half of that.And I have no idea how efficient ST-Link protocol is.

author: lucazader
author_rank: Regular Contributor
timestamp: May 30, 2021, 09:45:49 pm
content: IIRC the St-link-V2 only supports up to 2M swd frequency.And as ataradov mentioned it is a USB 2.0 FS (12Mbps) device.If you want faster it may be better to move to an St-link-V3. it can do up to 24Mhz.The V3 is a USB 2.0 HS device (480M).If you really need the ISOL capability there is the B-STLINK-ISOL board which can be put on the standard ST-link-v3-set

author: Unixon
author_rank: Frequent Contributor
timestamp: May 30, 2021, 10:10:59 pm
content: Quote from: SiliconWizard on May 30, 2021, 08:13:31 pmI'm sorry for poor selection of words. What I was trying to say is that every software and hardware layer from IDE to MCU introduces its own delays at every request-response cycle and all of them contribute to total latency while executing debugger commands. I don't know what makes the debugging slower than expected - big latency or low throughput. Picking a fight against latency will probably result in a waste of time, so at least I'm thinking of increasing throughput by accelerating SWD interface.Maybe I'm wrong and it's already operating at top speed, then I can't see what else could be done.So, the idea in short:0) Target MCU is reset and halted. OpenOCD adapter speed is set to safe value.1) OpenOCD tells MCU to switch on HSE, PLL, etc and continue at full speed by writing to RCC registers.2) OpenOCD waits until MCU stabilizes at new clock speed.3) OpenOCD verifies that clock switching went OK and changes adapter speed accordingly.4) OpenOCD is ready to accept GDB connections for remote debugging, but now it's times faster.

author: Unixon
author_rank: Frequent Contributor
timestamp: May 30, 2021, 10:14:01 pm
content: Quote from: lucazader on May 30, 2021, 09:45:49 pmThen there's no way to run it fasterQuote from: lucazader on May 30, 2021, 09:45:49 pmOK, thanks, I guess this costs a ton of money nowadays...

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 30, 2021, 10:22:52 pm
content: Quote from: Unixon on May 30, 2021, 10:10:59 pmWhat IDE are you using? I've used OpenOCD+GDB directly from the command line, and OpenOCD should remain active and connected at all times while you're debugging. I don't know how your IDE handles it. Hopefully it doesn't re-launch OpenOCD all the time during a debug session? You can check that the OpenOCD process remains active.If in doubt, you could try OpenOCD+GDB directly (outside of your IDE) on the command line, and see how "responsive" it is.

author: lucazader
author_rank: Regular Contributor
timestamp: May 30, 2021, 10:44:47 pm
content: Quote from: Unixon on May 30, 2021, 10:14:01 pmNah the st=link-v3 are pretty affordable.$35 usd for the v3-set from digikey in stock -https://www.digikey.com/en/products/detail/stmicroelectronics/STLINK-V3SET/9636028and if you dont need the isol capability you can use the v3mini which is ~$10 form digikey in stock -https://www.digikey.com/en/products/detail/stmicroelectronics/STLINK-V3MINI/10266291

author: Unixon
author_rank: Frequent Contributor
timestamp: May 30, 2021, 10:57:58 pm
content: Quote from: SiliconWizard on May 30, 2021, 10:22:52 pmFor MCU projects I'm sticking with Code::Blocks IDE, it's pretty good IDE overall, works well for local debugging but less for remote debugging and for MCU projects as it's not really specialized bit of software for that purpose. Commercial and Windows-only IDEs are out of the question, Eclipse-based IDEs are slow as hell.I'm starting OpenOCD manually from shell when I need it, generally after uploading new firmware. I know GDB can do it for me, but I don't want to reflash MCU each time I start a debugging session, so it's more convenient to reflash it with shell script and restart OpenOCD the same way.Quote from: SiliconWizard on May 30, 2021, 10:22:52 pmFirmware uploading takes about the same time, and overall responsiveness is probably better but irrelative since I can't navigate naked GDB fast enough and then it's not me waiting for the system, the system waits for me.