Closed gromero closed 1 year ago
@galak @erwango Erwan, before changing Zephyr to pick up board/stm32f746g-disco.cfg
instead of board/stm32f7discovery.cfg
(which was obsoleted by commit https://github.com/zephyrproject-rtos/openocd/commit/f79c902686f3ae500f3426dc2e552fdec80796d1), and per our discussion on Slack this week, it's necessary to fix the adapter speed in reset-start. I'll proceed to send another PR to Zephyr addressing the change we've discussed. Thanks.
Pushed a v2 fixing a nit in the comments.
Have you sent this to upstream openocd?
@galak Hi. Nope, I haven't yet. Do you prefer I submit there first? I was unsure because I don't how Zephyr's openocd how / when currently it syncs with upstream openocd.
@galak Hi. Nope, I haven't yet. Do you prefer I submit there first? I was unsure because I don't how Zephyr's openocd how / when currently it syncs with upstream openocd.
yes, preference is upstream first
@gromero can't this be put directly in boards/arm/stm32f746g_disco/support/openocd.cfg
?
yes, preference is upstream first
Got it. Let me work that out on openocd upstream. I'll get back here once I'm done there. Thanks.
BTW, I'm struggling to understand why commit f79c902686f3ae500f3426dc2e552fdec80796d1
is on branch zephyr-20200722
but not on master
branch? Isn't zephyr-20200722
created based upon master
? (note that I've based my change on zephyr-20200722 branch, not on master). Do you know why that happens?
@gromero can't this be put directly in
boards/arm/stm32f746g_disco/support/openocd.cfg
?
Hi Erwan! Yep, that would work too, but I think the correct approach is to get it fixed on openocd side, upstream (as @galak requested and actually that what I was planning, I just didn't know how/when Zephyr's openocd synced with openocd upstream)
If we apply the change only to openocd.cfg
it only affects Zephyr, right?
Closing as stale
Hi,
Could I get reviews for the following change that affects only ST STM32F746G Discovery boards, please?
Currently board/stm32f746g-disco.cfg already uses the maximum adapter speed available for reset-init events (4000 kHz). However it doesn't set that speed for reset-start events and so the speed for that event is inherited from the included config file arget/stm32f7x.cfg, which sets that speed to just 2000 kHz.
That commit overrides the inherited speed for reset-start events setting the adapter speed to be equal to the one used for reset-init events, i.e. to its maximum speed (4000 kHz).
That change avoids the following messages to appear when fashing the board:
Like, for instance, in:
It also increases the throughput a bit when flashing the device.
Thanks, Gustavo