-
Notifications
You must be signed in to change notification settings - Fork 243
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
rttConfig.enable does nothing (arm gdb + blackmagicprobe on stlink). here is the proof + workaround #1065
Comments
We don't have BMP hardware. We only enabled what we could test. Questions/comments
Usage or RTT implies that BMP implemented what SEGGER does.
What happens if you don't disable it when the debug session ends? CC: @ssimek Do you know about this? RTT is far more performant than SWO can ever be. Both require manual instrumentation and flow control. Since SEGGER put it in the public domain, more gdb servers are implementing it. |
@albmef true, rttConfig is currently not handled on BMP but it easily could, I'll look into it. @haneefdm the simple config is what BMP is about :) And yes, BMP has RTT support, just not in the standard builds for some reason. I have never played with it until now, I just remember looking at it some time ago but I was quite happy with SWO until now. SEGGER's performance claim is marketing BS to a degree, they are comparing filling a memory buffer that will be later read by the debug probe with synchronously waiting on a UART-like device. Running SWO at reasonable speeds (several MHz) removes most of the waiting. They also need a pretty beefy MCU to make the claim that they were outputting 82 characters in a microsecond - an average ~80 MHz one would hardly be able to output more than one character in one CPU clock cycle 🙄 |
Yes, I know and I have tried it in a real application. While it is faster than SWO, definitely not 100x. The 100x is mostly FW performance (cycles) for writing to SRAM vs SWO writing to registers with a tiny FIFO. Not the gdb-server reading the RTT buffer. I was limited by the probe USB performance though. And, our board TX-UART (SWO) is unreliable even at 1 Mbit. It doesn't matter how fast the processor could run. Our IOs were limited to 33 MHz toggle rate as well. In my application I was not just banging on the buffer in a loop. I had things to sense and calculate and then shove semi-large quantities of bytes into a buffer for the host to see. We also could not afford a pin to dedicate to SWO and using the SWD pins was more convenient. Looking at https://black-magic.org/usage/rtt.html they do have the other config items for RTT. Most important of those is this
There is also a question of timing. Since the RTT control block is initialized in FW sometime after main, looking for it will fail if done at reset. Or you may pickup stale/wrong information from a previous run. Especially if the linker moved the control block. Btw, some of the new crop of chips may not even have SWO. I was already part of developing one chip with no SWO because it was a multi-core setup and had to go with ARMs recommendation. |
Yep, I'm definitely intrigued in RTT and will work on adding proper support with the BMP. Regarding the config - I presume they are doing an autoscan if the addresses are not specified, I guess JLink is doing the same from what I understood. There definitely are cores without SWO, for example M0/M0+, and I completely understand the need for an extra pin can be an issue sometimes. Another thing that comes to mind is the USB-C SBU1/2 connection to SWCLK/SWDIO would be a lot more useful with RTT. @haneefdm can you assign this ticket to me so it's not lost in the sands of time? |
Yes, but it takes quite a bit of SWD bandwidth to scan the entire SRAM. One scan may not work. They could also find the wrong control block. With other gdb-servers, we typically know the exact address and we pass that along. It is almost free. Just assigned this to you. |
hi !
below is the proof that enabling rtt with just rttconfig.enable just does not work (on my config)
setup:
prior each test i manually disable the rtt by either doing a cold start, or typing monitor rtt disable in a gdb CLI
first test:
launch.json
here is the log from debug console
RESULT : nothing in the RTT output console (attached to /dev/ttyDmpTarg) !!!!
second test:
launch.json
here the log:
RESULT: RTT shows something
TADAAAWWWWW !
feel free to ask if you need more info i'd be happy to help
AM
The text was updated successfully, but these errors were encountered: