bmp enhancements; swo support #20
Comments
|
This is on my radar. From the description on the BMP wiki it doesn't sound too difficult for the basic logic (although I haven't looked into the actual code of it, either for Orbuculum or the example linked on the wiki, because of the licensing issues; although I have been reading your blog with great interest). Unfortunately it is a bit more difficult than it would appear because of the Visual Studio Code environment. The need to do raw access to the USB device, via libusb, presents some difficulty. The JavaScript environment for extensions causes issues as it doesn't naturally expose direct access to USB devices (like it does for Network sockets or file access, used for J-Link and OpenOCD respectively). While I can in theory add binary modules for extending the capabilities (as I have done for the serial port mode) - I haven't yet been able to build a libusb module that is compatible with the VS Code environment. Once I have that roadblock sorted out, then I will likely work on adding native support for SWO from BMP (at least on platforms where I am able to get the module built). |
|
If you want other licenses for Orbuculum code (or any modifications
doing to it), just let me know. Procedural crud mustn't stop you
getting this done :-)
Regards
DAVE
…On 16/02/18 15:38, Marcel Ball wrote:
This is on my radar. From the description on the BMP wiki it doesn't
sound too difficult for the basic logic (although I haven't looked
into the actual code of it, either for Orbuculum or the example linked
on the wiki, because of the licensing issues; although I have been
reading your blog with great interest). Unfortunately it is a bit more
difficult than it would appear because of the Visual Studio Code
environment.
The need to do raw access to the USB device, via libusb, presents some
difficulty. The JavaScript environment for extensions causes issues as
it doesn't naturally expose direct access to USB devices (like it does
for Network sockets or file access, used for J-Link and OpenOCD
respectively). While I can in theory add binary modules for extending
the capabilities (as I have done for the serial port mode) - I haven't
yet been able to build a libusb module that is compatible with the VS
Code environment. Once I have that roadblock sorted out, then I will
likely work on adding native support for SWO from BMP (at least on
platforms where I am able to get the module built).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFMwj32BLO1u1CYIWlMP4KBgxaEhfKLNks5tVaEDgaJpZM4SIVKa>.
|
|
I did make some progress on this item - but isn't ready for release yet. Was able to get the binary module I need for VS Code compiling (at least on Linux and OS X; haven't figured it out for Windows). Still running into some issues with getting the data off the device reliably. Not sure if it is an issue with the library, or a mistake in how I'm trying to use it (haven't done much with USB programming on either host or device side, so need to look into it more). If for example - I try to read 64 bytes off of the end point with a timeout of 100 milliseconds (particular values don't actually matter) - if at least 64 bytes were available then they get read off the device and processed properly. If the full 64 bytes weren't available then whatever data should have been collected seems to disappear completely and will never be received. Since I can't predict the exact speed that data will be available I run into problems (if I try to read faster than it is available it seems to disappear, but can't go slower than it is available as obviously buffers will fill up). Don't know if you encountered anything like that in your work? |
|
Hi, the SWO support is now officially in the BMP, and having access to this would be really good! I have hardware and can test if there are additions that need testing. |
|
Looking forward to SWO support for the BMP, this could be useful both in our research projects and in education (where we promote vscode + cortex debug). Overall impressions from the students are good, BMP might be another step forward. |
|
Highly recommend you go nick code out of Orbuculum for this job...multi
channel SWO would be a wonderful thing to have. If the license is a
problem then let me know and I'll change it to something that you are
more comfortable with.
DAVE
…On 28/06/18 14:04, perlindgren wrote:
Looking forward to SWO support for the BMP, this could be useful both
in our research projects and in education (where we promote vscode +
cortex debug). Overall impressions from the students are good, BMP
might be another step forward.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFMwj1fe42UMd8Me-vqtb_gmH_NSdZO3ks5uBNR0gaJpZM4SIVKa>.
|
|
I have been working on this, but currently I'm running into an issue with the libusb library for node where I'm either getting lost data and/or significantly delayed data. Once I can get past that issue it should be fairly quick to complete. Going to try to have another look at this in the next couple of weeks. |
|
Hi, |
|
Hi, |
|
Take a look at orbuculum, it'll do what you want. @Marus the code has nowadays be librified so would hopefully be easier to incorporate, and I'd be very happy to see it in there. Opencd and pyocd both have native orbuculum support now (see instructions in the orbuculum readme). bmp always did have. |
sync with marus master
|
@PhilippHaefele the current support is for the native hardware using Manchester only, I guess it needs a bit more work to enable SWO. Do you have a way to test it? |
|
Ummm. Shouldn't the support be for UART vs. Manchester? JLink for instance doesn't even support Manchester Openocd supports both UART and Manchester. We (cortex-debug) configures openocd (by default) in UART mode. Btw, most failures in SWO occur because the clock is not setup. Some vendors need a divider adjustment and in some devices, the clock feeding the HW has to be enabled somewhere in their proprietary MMIO register. Also, many users configure/setup their TPIU/ITM in FW and not rely on the debugger. |
|
@haneefdm This doesn't have much to do with other adapters, just BMP. The native hardware is Manchester-only (the future revision should have a UART option as well). What I meant by my previous comment is that the BMP SWO support is currently Manchester-only, but it's easy to add the switch - it's the second (optional) parameter to the BaseSWO helper. It's currently hardcoded to 1 (Manchester) for BMP. What's worse is that the future 2.x BMP firmware has changed the configuration command syntax ( |
|
As for people configuring SWO in the firmware, I'm aware of this practice (though I strongly disagree with it). Do you know how those users are working with cortex-debug? To the best of my knowledge, there is no way to skip the SWO init commands if SWO is enabled, which can lead to confusing results (since the registers are configured from two places), to say the least... |
|
It works just fine. What we do, it gets overridden by FW in their main. This is also why I provide the scripts for GDB and Openocd in case they wan't to use that method.
We can disagree all we want but users do what they are used to. I can't convince them otherwise. The trend started by many web pages on the internet and examples from various device vendors and even SEGGER. It predates Cortex-Debug. In one case, I HAD to do it in FW for my device because of how the clock tree was setup. I disagree with that HW implementation but couldn't change it. IMO is it more reliable to do it in FW as you know exactly what is going on. There are other things I do with the ITM/TPIU besides SWO as well. I also have to make sure I don't overflow the FIFO in my putc() |
:-) We are at the end of the food chain and this happens. AFAIK, this would be the first instance where we are doing a Q&A with the gdb-server at startup?
The HW in question is the target device? So, they made themselves incompatible with SEGGER? Thats bold. What device is this? Or the HW in question is the BMP? |
Yes, the BMP probe itself. Target is an overloaded term in this case, as the BMP firmware itself runs in many targets, one of which is the BMP hardware. The terminology is pretty confusing (and I have definitely misused it in this case as well), they actually have a page explaining everything 😆 |
|
Back to the question @PhilippHaefele originally asked. Can we close this issue while we wait for BMP to add the required support? |
|
Just let me add the config to choose between Manchester and NRZ/UART and we can close it. I hope to get to it tonight. It can actually be pretty useful to be able to choose in general. |
Refs: bmp enhancements; swo support Marus#20
|
@PhilippHaefele If you have a non-native BMP-running probe available, can you please give https://github.com/Marus/cortex-debug/actions/runs/12774912645?pr=1073 a try? It should work, but I'd like to be sure. |
I will try to convert a st-link and do a test. Hoping to do this soon, as I'm quite busy right now |
Would it be possible for you to add swo support for the bmp? The code to do this is relatively straightforward (See https://github.com/mubes/orbuculum/blob/master/Src/orbuculum.c around line 1202 ... there may be other stuff in Orbuculum you can make use of too) but does need to be enabled via a suitable monitor command (
monitor traceswofor 'standard' bmpmonitor traceswo <speed>for bluepill or bmp with async swo support). When parallel trace support is in place this will probably be enabled by a similar mechanism.The text was updated successfully, but these errors were encountered: