Feature: re-enable non-halting RTT on a few targets #2037
+54
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Detailed description
Testcases are Arduino/stm32duino RTT_Stream speedtest.ino sketch and Eclipse uOS++ ilie with Segger's RTT sources from their examples zip. Unfortunately I haven't been able to find an independent opensource implementation of RTT to include in libopencm3-based firmware testcases, and I don't want to dip in Rust for this.
Confirmed to increase RTT data read speed on Nucleo-G071RB and GD32E508ZE, to stop dropping Rx SPI words on WeAct Studio AT32F403ACG.
Pending testing on STM32F103CB, GD32F103CB, GD32F303CC (all WeAct Studio BluePill-Plus boards).
BMP platform used is mostly
blackpill-f411ce
but stlink/swlink is also possible. BMDA is likewise affected.Note I cannot test GD32F2 and GD32E230, where it is unknown to work. Especially so I cannot test on TM4C123 which is the one and only reported problematic Cortex-M4F core.
A good metric of detecting DUT halts without parsing SWD traffic or BMP advanced logging or running any realtime communication protocols (or wiggling GPIOs) is running a peripheral TIMer in Output PWM mode at 100% duty cycle with DBGMCU APB freeze bit set for it -- as soon as Processing Element gets halted, TIM_OCx goes low (confirmed on oscilloscope watching SWD), and goes back high on resuming, and there's no extra spurious transitions.
First commit (which touches target/cortexm.c) is obviously not intended to land on
main
as part of this PR, it is only provided for convenience of A/B-testing without reflashing BMPs (there's a runtime switch formonitor mem_nohalt enable
)If wildcard-enabling this behaviour on entire families not flavours is acceptable, then I can move the flag-setting code out of branches and simplify firmware further.
Your checklist for this pull request
Closing issues