Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: re-enable non-halting RTT on a few targets #2037

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

ALTracer
Copy link
Contributor

Detailed description

  • This is not a new feature, this restores BMD behaviour before Fix: Memory access halting heuristic #1962.
  • The existing problem is BMP with RTT halts all its targets by default to check controlblock contents in SRAM. This is incompatible with any real-time firmware, we get packet loss and CRC errors.
  • The PR solves it by enabling the provisioned target flag on targets where I've tested RTT to return non-garbage data even if the processor keeps running.

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 for monitor 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

@ALTracer ALTracer force-pushed the feature/mem_nohalt branch from f9c6183 to 8f49ae5 Compare January 6, 2025 03:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant