blackmagicdebug-devel Mailing List for Black Magic Debug Probe
An in-application debug probe for ARM Cortex-M microcontrollers.
Status: Beta
Brought to you by:
gsmcmullin
This list is closed, nobody may subscribe to it.
2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(4) |
Mar
(19) |
Apr
(29) |
May
(4) |
Jun
(5) |
Jul
(3) |
Aug
(13) |
Sep
|
Oct
(5) |
Nov
(10) |
Dec
(6) |
2014 |
Jan
(15) |
Feb
(3) |
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(7) |
Oct
|
Nov
(4) |
Dec
(3) |
2015 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
(4) |
Feb
(10) |
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Piotr Esden-T. <pi...@es...> - 2022-01-07 22:14:09
|
Hi everyone! As some of you might know this project was created and maintained for many years by Gareth McMullin[1]. He has created a wonderful tool that we all use and love. You might have also noticed that Gareth did not have much time to dedicate to the project for the last few years. He asked me a while ago if I would be able to take over the project and become an official maintainer of Black Magic Debug. I did not have the necessary resources to dedicate to the project until very recently. But it is finally time, from now on I am officially taking on the position as the Black Magic Debug maintainer. :) I want to thank Gareth for putting the faith in me and creating this amazing project. I also have to say big thanks to Uwe Bonnes[2] who stepped in while Gareth and I were unavailable to keep the patches and Black Magic releases going. I have a lot of plans for the Black Magic project, software/firmware and hardware wise. You might have noticed I already spent some time catching up on and cleaning the github issues. It is by no means finished and probably never will be, but I hope we can keep open issues and pull requests on a better level going forward. To resolve the issue that the native Black Magic Hardware is currently not available due to chip shortages, I am working on the new revision of the native hardware. This should make them available again and allow us for more alternative chip choices. We are adding some cool new features to the new hardware while we are at it. (more information soon) I am also working on a tool that will help users manage the Black Magic Probe firmware, opening doors to more flexibility and versatility of the project overall. (also, more information about that soon) You can also expect that we will finally get a proper CI system including HITL (Hardware In The Loop) testing. Something we are in dire need to keep the stability expectations as high as possible. I was collecting a lot of hardware over the years and I want to put it together to some good use. We will also improve the contribution process and document the APIs better, this should hopefully make addition of new targets easier. There is one more thing that I would like to mention. In the process of changing maintainership the github organization that the project is under will be changing it's name. As it is not developed by Blacksphere (Gareth's consulting company) we will be renaming the org to the project's name itself. It will serve as an umbrella for additional repositories related to the Black Magic Debug project. Don't worry github should redirect the old organization names to the new one. I hope it will not cause too much disruption. We will also finally be officially retiring the SourceForge project page to avoid confusion. This means the old unused mailing lists will be disabled. If you have questions or concerns and want to get in touch with the project you have multiple options: open an issue on github[3], join the 1BitSquared Discord server[4] and talk to us in the #blackmagic channel. If it is something you would rather discuss one on one, you can also write an email to: contact at black-magic org where you will be able to reach the core developer team. I am excited to work with you all to bring the Black Magic Debug project to the next level. Stay safe, cheers, Piotr Esden-Tempski [1](https://github.com/gsmcmullin) [2](https://github.com/UweBonnes) [3](https://github.com/blacksphere/blackmagic/issues) [4](https://1bitsquared.com/pages/chat) |
From: <kri...@te...> - 2019-09-09 17:38:53
|
Sorry, I got a little error in my previous e-mail. In the function get_comport ( self , purpose : str ), the second and third lines should be: subclass = "MI_00" if purpose == "gdb" else "MI_02" cmd = f"REG QUERY \" HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Enum \\ USB \\{ vid } & { subclass }\" /s /f \" FriendlyName \" /t \" REG_SZ \" " Sorry for the inconvenience. Kind greetings, Kristof Van: "kristof mulier" <kri...@te...> Aan: "Dave Marples" <da...@ma...> Cc: "blackmagicdebug-devel" <bla...@li...> Verzonden: Maandag 9 september 2019 19:35:02 Onderwerp: Re: [blackmagic] Black Magic Probe for new microcontroller IDE Hi Dave, Thank you for your help. Thanks to your latest mail, I managed to support the Black Magic Probe in Embeetle IDE (well, the alpha is not yet launched, but my development version here works with BMP now!). I'll share the Python code here. My first function get_usb_vid_and_pid ( self ) finds out the Vendor ID and Product ID from the Black Magic Probe. The Vendor ID should be stable, but I suppose the Product ID can change. It felt more "robust" to extract both from the registry (through a Windows console command) instead of having them hardcoded. Here is my code: def get_usb_vid_and_pid ( self ) -> str : ''' Get USB Vendor ID and Product ID. ''' cmd = "REG QUERY HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Enum \\ USB \\ /s /f \" DeviceDesc \" /t \" REG_SZ \" " process = subprocess. Popen (cmd, stdout =subprocess.PIPE) output_ch, error_ch = process. communicate () output = output_ch. decode (). replace ( ' \r\n ' , ' \n ' ). split ( ' \n ' ) vid_line = None vid = None # 1. Get the line with VID & PID. for i in range ( len (output)): line = output[i] if "black magic" in line. lower (): vid_line = output[i - 1 ] break if vid_line is None : return None # 2. Get the full VID & PID with subclass. vid_line = vid_line. replace ( ' \\ ' , '/' ) temp = vid_line. split ( '/' ) for t in temp: if t. lower (). startswith ( "vid" ): vid = t break if vid is None : return None # 3. Extract only the VID & PID. try : p = re. compile ( r"&MI_\d*" ) vid = p. sub ( '' , vid) except Exception as e: pass return vid This function returns the string "VID_1D50&PID_6018" on my computer. Next, I got the following Python function to extract the COM-ports: def get_comport ( self , purpose : str ) -> int : ''' Get virtual COM-port number for :param purpose: "gdb" -> GDB server "uart" -> UART interface ''' vid = self . get_usb_vid_and_pid () subclass = "&MI_00" if purpose == "gdb" else "&MI_02" cmd = f"REG QUERY \" HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Enum \\ USB \\{ vid } &MI_00 \" /s /f \" FriendlyName \" /t \" REG_SZ \" " process = subprocess. Popen (cmd, stdout =subprocess.PIPE) output_ch, error_ch = process. communicate () output = output_ch. decode (). replace ( ' \r\n ' , ' \n ' ). split ( ' \n ' ) # 1. Get the line with the COM-port. comport_line = None for line in output: if "FriendlyName" in line and "COM" in line: comport_line = line break # 2. Extract the COM-port. comport = None portnr = None p = re. compile ( r"COM\d*" ) comport = p. search (comport_line). group ( 0 ) portnr = int (comport. replace ( "COM" , '' )) return portnr If I call the function get_comport ( "gdb" ), I get 31 returned. If I call get_comport ( "uart" ) I get 32 returned. That's correct :-) Many thanks to Mr. Dave Marples for helping me! Kind greetings, Kristof Mulier Van: "Dave Marples" <da...@ma...> Aan: "kristof mulier" <kri...@te...> Cc: "blackmagicdebug-devel" <bla...@li...> Verzonden: Maandag 9 september 2019 14:53:03 Onderwerp: Re: [blackmagic] Black Magic Probe for new microcontroller IDE On 09/09/2019 13:46, [ mailto:kri...@te... | kri...@te... ] wrote: Hi Dave, Thank you very much for your answer. So I issue the first command from your mail, to get all the USB devices: REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "DeviceDesc" /t "REG_SZ" This command generates 361 outputs, from which the following seem related to the Black Magic Probe: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 \C1DBAEF7 DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 \7&4bc2d51&0&0000 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 \7&4bc2d51&0&0002 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_04 \7&4bc2d51&0&0004 DeviceDesc REG_SZ Black Magic Firmware Upgrade HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_05 \7&4bc2d51&0&0005 DeviceDesc REG_SZ Black Magic Trace Capture So this means that the Black Magic Probe's Vendor ID is VID_1D50&PID_6018 with five sub-classes: MI_00 -> The GDB-server (virtual COM-port) MI_01 -> ? MI_02 -> The UART interface (virtual COM-port) MI_03 -> ? MI_04 -> The firmware upgrade MI_05 -> The Trace Capture (SWO) Is this correct? MI_01 & MI_03 are the data interfaces for the serial port, and don't appear separately because they're 'consumed' in the association descriptor....but in any case, I went the long way around :-) Since 1d50:6018 should only ever be a BMP, you should be able to avoid this step, and just go directly for the registry queries below. BQ_BEGIN Now I get your point: the virtual COM-port subclasses MI_00 and MI_02 don't reveal the name Black Magic , causing confusion. You use the MI_04 and MI_05 subclasses instead to identify the Vendor ID - because these subclasses do reveal the name Black Magic . Once you got the Vendor ID, you issue the following commands to know the COM-port numbers: 1. To get the COM-port number for the GDB-server: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM31) 2. To get the COM-port number for the UART interface: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM32) Is my interpretation of your answer correct? BQ_END Yes, but you only need this last step, don't worry about the rest. Later you will also want MI_05 for SWO, but we'll worry about that when we get to it. BQ_BEGIN Your workaround is brilliant! It's a big help. Now I think I can get the black magic probe to work "out-of-the-box" in our IDE. Thank you so much! BQ_END NP. You'll get support more quickly on the discord group, so please go join that. This link only lasts 24 hours though; [ https://discord.gg/sFX4tt | https://discord.gg/sFX4tt ] You should probably also update your BMP to the latest version, but it would be best to ask on the group what that actually is...or look on the homepage. DAVE |
From: <kri...@te...> - 2019-09-09 17:35:13
|
Hi Dave, Thank you for your help. Thanks to your latest mail, I managed to support the Black Magic Probe in Embeetle IDE (well, the alpha is not yet launched, but my development version here works with BMP now!). I'll share the Python code here. My first function get_usb_vid_and_pid ( self ) finds out the Vendor ID and Product ID from the Black Magic Probe. The Vendor ID should be stable, but I suppose the Product ID can change. It felt more "robust" to extract both from the registry (through a Windows console command) instead of having them hardcoded. Here is my code: def get_usb_vid_and_pid ( self ) -> str : ''' Get USB Vendor ID and Product ID. ''' cmd = "REG QUERY HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Enum \\ USB \\ /s /f \" DeviceDesc \" /t \" REG_SZ \" " process = subprocess. Popen (cmd, stdout =subprocess.PIPE) output_ch, error_ch = process. communicate () output = output_ch. decode (). replace ( ' \r\n ' , ' \n ' ). split ( ' \n ' ) vid_line = None vid = None # 1. Get the line with VID & PID. for i in range ( len (output)): line = output[i] if "black magic" in line. lower (): vid_line = output[i - 1 ] break if vid_line is None : return None # 2. Get the full VID & PID with subclass. vid_line = vid_line. replace ( ' \\ ' , '/' ) temp = vid_line. split ( '/' ) for t in temp: if t. lower (). startswith ( "vid" ): vid = t break if vid is None : return None # 3. Extract only the VID & PID. try : p = re. compile ( r"&MI_\d*" ) vid = p. sub ( '' , vid) except Exception as e: pass return vid This function returns the string "VID_1D50&PID_6018" on my computer. Next, I got the following Python function to extract the COM-ports: def get_comport ( self , purpose : str ) -> int : ''' Get virtual COM-port number for :param purpose: "gdb" -> GDB server "uart" -> UART interface ''' vid = self . get_usb_vid_and_pid () subclass = "&MI_00" if purpose == "gdb" else "&MI_02" cmd = f"REG QUERY \" HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Enum \\ USB \\{ vid } &MI_00 \" /s /f \" FriendlyName \" /t \" REG_SZ \" " process = subprocess. Popen (cmd, stdout =subprocess.PIPE) output_ch, error_ch = process. communicate () output = output_ch. decode (). replace ( ' \r\n ' , ' \n ' ). split ( ' \n ' ) # 1. Get the line with the COM-port. comport_line = None for line in output: if "FriendlyName" in line and "COM" in line: comport_line = line break # 2. Extract the COM-port. comport = None portnr = None p = re. compile ( r"COM\d*" ) comport = p. search (comport_line). group ( 0 ) portnr = int (comport. replace ( "COM" , '' )) return portnr If I call the function get_comport ( " gdb" ), I get 31 returned. If I call get_comport ( "uart" ) I get 32 returned. That's correct :-) Many thanks to Mr. Dave Marples for helping me! Kind greetings, Kristof Mulier Van: "Dave Marples" <da...@ma...> Aan: "kristof mulier" <kri...@te...> Cc: "blackmagicdebug-devel" <bla...@li...> Verzonden: Maandag 9 september 2019 14:53:03 Onderwerp: Re: [blackmagic] Black Magic Probe for new microcontroller IDE On 09/09/2019 13:46, [ mailto:kri...@te... | kri...@te... ] wrote: Hi Dave, Thank you very much for your answer. So I issue the first command from your mail, to get all the USB devices: REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "DeviceDesc" /t "REG_SZ" This command generates 361 outputs, from which the following seem related to the Black Magic Probe: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 \C1DBAEF7 DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 \7&4bc2d51&0&0000 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 \7&4bc2d51&0&0002 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_04 \7&4bc2d51&0&0004 DeviceDesc REG_SZ Black Magic Firmware Upgrade HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_05 \7&4bc2d51&0&0005 DeviceDesc REG_SZ Black Magic Trace Capture So this means that the Black Magic Probe's Vendor ID is VID_1D50&PID_6018 with five sub-classes: MI_00 -> The GDB-server (virtual COM-port) MI_01 -> ? MI_02 -> The UART interface (virtual COM-port) MI_03 -> ? MI_04 -> The firmware upgrade MI_05 -> The Trace Capture (SWO) Is this correct? MI_01 & MI_03 are the data interfaces for the serial port, and don't appear separately because they're 'consumed' in the association descriptor....but in any case, I went the long way around :-) Since 1d50:6018 should only ever be a BMP, you should be able to avoid this step, and just go directly for the registry queries below. BQ_BEGIN Now I get your point: the virtual COM-port subclasses MI_00 and MI_02 don't reveal the name Black Magic , causing confusion. You use the MI_04 and MI_05 subclasses instead to identify the Vendor ID - because these subclasses do reveal the name Black Magic . Once you got the Vendor ID, you issue the following commands to know the COM-port numbers: 1. To get the COM-port number for the GDB-server: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM31) 2. To get the COM-port number for the UART interface: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM32) Is my interpretation of your answer correct? BQ_END Yes, but you only need this last step, don't worry about the rest. Later you will also want MI_05 for SWO, but we'll worry about that when we get to it. BQ_BEGIN Your workaround is brilliant! It's a big help. Now I think I can get the black magic probe to work "out-of-the-box" in our IDE. Thank you so much! BQ_END NP. You'll get support more quickly on the discord group, so please go join that. This link only lasts 24 hours though; [ https://discord.gg/sFX4tt | https://discord.gg/sFX4tt ] You should probably also update your BMP to the latest version, but it would be best to ask on the group what that actually is...or look on the homepage. DAVE |
From: Dave M. <da...@ma...> - 2019-09-09 12:53:20
|
On 09/09/2019 13:46, kri...@te... wrote: > Hi Dave, > > Thank you very much for your answer. > So I issue the first command from your mail, to get all the USB devices: > > REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f > "DeviceDesc" /t "REG_SZ" > > > This command generates 361 outputs, from which the following seem > related to the Black Magic Probe: > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018\C1DBAEF7 > DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite > Device > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\7&4bc2d51&0&0000 > DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\7&4bc2d51&0&0002 > DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_04\7&4bc2d51&0&0004 > DeviceDesc REG_SZ Black Magic Firmware Upgrade > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_05\7&4bc2d51&0&0005 > DeviceDesc REG_SZ Black Magic Trace Capture > > So this means that the Black Magic Probe's Vendor ID is > VID_1D50&PID_6018 with five sub-classes: > > MI_00 -> The GDB-server (virtual COM-port) > MI_01 -> ? > MI_02 -> The UART interface (virtual COM-port) > MI_03 -> ? > MI_04 -> The firmware upgrade > MI_05 -> The Trace Capture (SWO) > > Is this correct? > MI_01 & MI_03 are the data interfaces for the serial port, and don't appear separately because they're 'consumed' in the association descriptor....but in any case, I went the long way around :-) Since 1d50:6018 should only ever be a BMP, you should be able to avoid this step, and just go directly for the registry queries below. > Now I get your point: the virtual COM-port subclasses MI_00 and MI_02 > don't reveal the name /Black Magic/, causing confusion. You use the > MI_04 and MI_05 subclasses instead to identify the Vendor ID - because > these subclasses do reveal the name /Black Magic/. Once you got the > Vendor ID, you issue the following commands to know the COM-port numbers: > > 1. To get the COM-port number for the GDB-server: > > REG QUERY > "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00" > /s /f "FriendlyName" /t "REG_SZ" > FriendlyName REG_SZ USB Serial Device (COM31) > > 2. To get the COM-port number for the UART interface: > > REG QUERY > "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02" > /s /f "FriendlyName" /t "REG_SZ" > FriendlyName REG_SZ USB Serial Device (COM32) > > Is my interpretation of your answer correct? Yes, but you only need this last step, don't worry about the rest. Later you will also want MI_05 for SWO, but we'll worry about that when we get to it. > Your workaround is brilliant! It's a big help. Now I think I can get > the black magic probe to work "out-of-the-box" in our IDE. Thank you > so much! NP. You'll get support more quickly on the discord group, so please go join that. This link only lasts 24 hours though; https://discord.gg/sFX4tt You should probably also update your BMP to the latest version, but it would be best to ask on the group what that actually is...or look on the homepage. DAVE |
From: <kri...@te...> - 2019-09-09 12:46:15
|
Hi Dave, Thank you very much for your answer. So I issue the first command from your mail, to get all the USB devices: REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "DeviceDesc" /t "REG_SZ" This command generates 361 outputs, from which the following seem related to the Black Magic Probe: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 \C1DBAEF7 DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 \7&4bc2d51&0&0000 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 \7&4bc2d51&0&0002 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_04 \7&4bc2d51&0&0004 DeviceDesc REG_SZ Black Magic Firmware Upgrade HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_05 \7&4bc2d51&0&0005 DeviceDesc REG_SZ Black Magic Trace Capture So this means that the Black Magic Probe's Vendor ID is VID_1D50&PID_6018 with five sub-classes: MI_00 -> The GDB-server (virtual COM-port) MI_01 -> ? MI_02 -> The UART interface (virtual COM-port) MI_03 -> ? MI_04 -> The firmware upgrade MI_05 -> The Trace Capture (SWO) Is this correct? Now I get your point: the virtual COM-port subclasses MI_00 and MI_02 don't reveal the name Black Magic , causing confusion. You use the MI_04 and MI_05 subclasses instead to identify the Vendor ID - because these subclasses do reveal the name Black Magic . Once you got the Vendor ID, you issue the following commands to know the COM-port numbers: 1. To get the COM-port number for the GDB-server: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_00 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM31) 2. To get the COM-port number for the UART interface: REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ VID_1D50&PID_6018 &MI_02 " /s /f "FriendlyName" /t "REG_SZ" FriendlyName REG_SZ USB Serial Device (COM32) Is my interpretation of your answer correct? Your workaround is brilliant! It's a big help. Now I think I can get the black magic probe to work "out-of-the-box" in our IDE. Thank you so much! Kind greetings, Kristof Mulier Van: "Dave Marples" <da...@ma...> Aan: "blackmagicdebug-devel" <bla...@li...> Verzonden: Maandag 9 september 2019 12:25:41 Onderwerp: Re: [blackmagic] Black Magic Probe for new microcontroller IDE OK, I took a quick look at this because I've been in amongst the usb code recently. String labeling the data and/or comm interfaces has no effect. It would appear that the doze class driver replaces the FriendlyName with "USB Serial Device (COMx)". Descriptors for other interfaces on the device ( that don't use the class driver ) are delivered correctly, for example; C:\WINDOWS\system32>REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "DeviceDesc" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018\7BAD7994 DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\6&eb2772&0&0000 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\6&eb2772&0&0002 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_04\6&eb2772&0&0004 DeviceDesc REG_SZ Black Magic Firmware Upgrade HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_05\6&eb2772&0&0005 DeviceDesc REG_SZ Black Magic Trace Capture So, easiest version; C:\WINDOWS\system32>REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00" /s /f "FriendlyName" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\6&eb2772&0&0000 FriendlyName REG_SZ USB Serial Device (COM5) C:\WINDOWS\system32>REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02" /s /f "FriendlyName" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\6&eb2772&0&0002 FriendlyName REG_SZ USB Serial Device (COM4) ...this _should_ work under all circumstances - note the order of the COM ports! There are probably quicker ways to get the result if you know Windows Registry query syntax, but I am not a member of that set. Good luck DAVE _______________________________________________ Blackmagicdebug-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: Dave M. <da...@ma...> - 2019-09-09 10:25:53
|
OK, I took a quick look at this because I've been in amongst the usb code recently. String labeling the data and/or comm interfaces has no effect. It would appear that the doze class driver replaces the FriendlyName with "USB Serial Device (COMx)". Descriptors for other interfaces on the device ( that don't use the class driver ) are delivered correctly, for example; C:\WINDOWS\system32>REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "DeviceDesc" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018\7BAD7994 DeviceDesc REG_SZ @usb.inf,%usb\composite.devicedesc%;USB Composite Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\6&eb2772&0&0000 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\6&eb2772&0&0002 DeviceDesc REG_SZ @usbser.inf,%usbserial.devicedesc%;USB Serial Device HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_04\6&eb2772&0&0004 DeviceDesc REG_SZ Black Magic Firmware Upgrade HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_05\6&eb2772&0&0005 DeviceDesc REG_SZ Black Magic Trace Capture So, easiest version; C:\WINDOWS\system32>REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00" /s /f "FriendlyName" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\6&eb2772&0&0000 FriendlyName REG_SZ USB Serial Device (COM5) C:\WINDOWS\system32>REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02" /s /f "FriendlyName" /t "REG_SZ" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\6&eb2772&0&0002 FriendlyName REG_SZ USB Serial Device (COM4) ...this _should_ work under all circumstances - note the order of the COM ports! There are probably quicker ways to get the result if you know Windows Registry query syntax, but I am not a member of that set. Good luck DAVE |
From: Dave M. <da...@ma...> - 2019-09-08 23:06:51
|
So...I just looked into this, and the 'friendly name' for the two ports (i.e. the strings that are pointed to) are already set to; "Black Magic GDB Server" and "Black Magic UART Port" However, these are set on the comm interfaces and not the data ones (which have their index set to zero). If you let me know what type of BMP you have we can try a build with the data interfaces also pointing to the strings to see if that makes doze happier. Regards DAVE On 08/09/2019 15:07, kri...@te... wrote: > Dear Black Magic Developers, > > I found a way to show the "FriendlyName" of each virtual COM-port on > Windows. > > First I issue the following console command to see all COM-ports that > are currently connected: > |> REG QUERY HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM| > I get the output: > |\Device\ssudmdm0000 REG_SZ COM7 \Device\USBSER000 REG_SZ > COM31 \Device\USBSER001 REG_SZ COM32 | > Next I issue a console command to ask all installed USB devices with > their "FriendlyName": > |> REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s > /f "FriendlyName" /t "REG_SZ"| > I get the output: > |HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0403&PID_EEEE\FTVX4O6F > FriendlyName REG_SZ USB Serial Port (COM21) > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_3748\066EFF524853837267105137 > FriendlyName REG_SZ STM32 STLink > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_374B&MI_00\6&4130aa4&0&0000 > FriendlyName REG_SZ ST-Link Debug > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_374B&MI_02\6&4130aa4&0&0002 > FriendlyName REG_SZ STMicroelectronics STLink Virtual COM Port (COM3) > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\7&4bc2d51&0&0000 > FriendlyName REG_SZ USB Serial Device (COM31) > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\7&4bc2d51&0&0002 > FriendlyName REG_SZ USB Serial Device (COM32) > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_2341&PID_0042\956353334313517052F1 > FriendlyName REG_SZ Arduino Mega 2560 (COM12) > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_2341&PID_0043\55736303731351816081 > FriendlyName REG_SZ Arduino Uno (COM11)| > > Next I can combine the output from the first and second command, to > know the friendly names of *COM7*, *COM31* and *COM32*: > |COM7 -> None COM31 -> USB Serial Device COM32 -> USB Serial Device | > Unfortunately, this doesn't help me much. I know from trial and error > that *COM31* is the Black Magic Probe's GDB server and *COM32* its > serial port. But I wouldn't be able to determine that purely from the > "friendly names" stored in the Windows registry. > > Do you know another way to determine the correct COM-port? > > > > ------------------------------------------------------------------------ > *Van: *"kristof mulier" <kri...@te...> > *Aan: *"blackmagicdebug-devel" > <bla...@li...> > *Cc: *"johan cockx" <joh...@si...>, "kukovecmatic" > <kuk...@ho...>, "Johan Cockx" <jc...@gm...> > *Verzonden: *Zondag 8 september 2019 15:17:13 > *Onderwerp: *[blackmagic] Black Magic Probe for new microcontroller IDE > > Dear Black Magic developers, > > We are working on a new C/C++ IDE for programming microcontrollers. > We've not yet launched the software, but you can have a sneak peak on > our test website: > > https://test.embeetle.com > > We would like to support your open-source Black Magic probe in the > IDE. Everything is well explained on your github page > (https://github.com/blacksphere/blackmagic/wiki/Getting-Started) so we > got the probe almost working in the IDE. There is just one more hurdle > to take, for which we'd need your help. > > *Connection on Linux* > To connect to the probe's virtual COM-port on Linux, one needs to > issue the gdb command: > |(gdb) target extended-remote /dev/ttyACM0| > In your FAQ, you give a solution to provide a stable name to this > virtual COM-port, like /dev/ttyBmpGdb . However, it's more problematic > on Windows... > > *Connection on Windows* > To connect to the probe's virtual COM-port on Windows, the command > would look like: > |(gdb) target extended-remote \\.\COM10| > However, the name of the COM-port is uknown beforehand. We cannot ask > our users to look up the COM-port in the device manager and fill it in > somewhere. We want it to work "out of the box". Is it possible to > detect the virtual COM-port's name automatically through some Windows > console command? Or perhaps a python command? > > Thank you very much for your help. > > Kind greetings, > > Kristof Mulier > > > > > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel > > > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: Dave M. <da...@ma...> - 2019-09-08 15:26:59
|
Kristof, If should be possible to fix this by means of adding Descriptive strings to the interface descriptor (see https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/standard-usb-descriptors ). I can take a look at it later but cannot test as I don't do doze. What kind of BMP do you have, I can build you an image to install on your device and try. Good luck with your project. A lightweight embedded ide is highly nessessary...I still haven't found one I'm happy with. PM me directly if you want to discuss integrating SWO into it. It looks like you're trying to build a business out of this, but please try to open source as much as you can...you're standing on the shoulders of giants to make this fly. Oh, and it's probably worth joining the BMP Discord channel for faster discussions. (An alternative - you should be able to query the usb database by vendor and device ID, which will get you close to what you want. Unfortunately recent doze has a habit of swapping the ports over, so it might not get you all the way home). Regards Dave On Sun, 8 Sep 2019, 14:17 , <kri...@te...> wrote: > Dear Black Magic developers, > > We are working on a new C/C++ IDE for programming microcontrollers. > We've not yet launched the software, but you can have a sneak peak on our > test website: > > https://test.embeetle.com > > We would like to support your open-source Black Magic probe in the IDE. > Everything is well explained on your github page ( > https://github.com/blacksphere/blackmagic/wiki/Getting-Started) so we got > the probe almost working in the IDE. There is just one more hurdle to take, > for which we'd need your help. > > *Connection on Linux* > To connect to the probe's virtual COM-port on Linux, one needs to issue > the gdb command: > > (gdb) target extended-remote /dev/ttyACM0 > > In your FAQ, you give a solution to provide a stable name to this virtual > COM-port, like /dev/ttyBmpGdb . However, it's more problematic on > Windows... > > *Connection on Windows* > To connect to the probe's virtual COM-port on Windows, the command would > look like: > > (gdb) target extended-remote \\.\COM10 > > However, the name of the COM-port is uknown beforehand. We cannot ask our > users to look up the COM-port in the device manager and fill it in > somewhere. We want it to work "out of the box". Is it possible to detect > the virtual COM-port's name automatically through some Windows console > command? Or perhaps a python command? > > Thank you very much for your help. > > Kind greetings, > > Kristof Mulier > > > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel > |
From: <kri...@te...> - 2019-09-08 14:08:08
|
Dear Black Magic Developers, I found a way to show the "FriendlyName" of each virtual COM-port on Windows. First I issue the following console command to see all COM-ports that are currently connected: > REG QUERY HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM I get the output: \Device\ssudmdm0000 REG_SZ COM7 \Device\USBSER000 REG_SZ COM31 \Device\USBSER001 REG_SZ COM32 Next I issue a console command to ask all installed USB devices with their "FriendlyName": > REG QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ /s /f "FriendlyName" /t "REG_SZ" I get the output: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0403&PID_EEEE\FTVX4O6F FriendlyName REG_SZ USB Serial Port (COM21) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_3748\066EFF524853837267105137 FriendlyName REG_SZ STM32 STLink HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_374B&MI_00\6&4130aa4&0&0000 FriendlyName REG_SZ ST-Link Debug HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_374B&MI_02\6&4130aa4&0&0002 FriendlyName REG_SZ STMicroelectronics STLink Virtual COM Port (COM3) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_00\7&4bc2d51&0&0000 FriendlyName REG_SZ USB Serial Device (COM31) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1D50&PID_6018&MI_02\7&4bc2d51&0&0002 FriendlyName REG_SZ USB Serial Device (COM32) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_2341&PID_0042\956353334313517052F1 FriendlyName REG_SZ Arduino Mega 2560 (COM12) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_2341&PID_0043\55736303731351816081 FriendlyName REG_SZ Arduino Uno (COM11) Next I can combine the output from the first and second command, to know the friendly names of COM7 , COM31 and COM32 : COM7 -> None COM31 -> USB Serial Device COM32 -> USB Serial Device Unfortunately, this doesn't help me much. I know from trial and error that COM31 is the Black Magic Probe's GDB server and COM32 its serial port. But I wouldn't be able to determine that purely from the "friendly names" stored in the Windows registry. Do you know another way to determine the correct COM-port? Van: "kristof mulier" <kri...@te...> Aan: "blackmagicdebug-devel" <bla...@li...> Cc: "johan cockx" <joh...@si...>, "kukovecmatic" <kuk...@ho...>, "Johan Cockx" <jc...@gm...> Verzonden: Zondag 8 september 2019 15:17:13 Onderwerp: [blackmagic] Black Magic Probe for new microcontroller IDE Dear Black Magic developers, We are working on a new C/C++ IDE for programming microcontrollers. We've not yet launched the software, but you can have a sneak peak on our test website: https://test.embeetle.com We would like to support your open-source Black Magic probe in the IDE. Everything is well explained on your github page (https://github.com/blacksphere/blackmagic/wiki/Getting-Started) so we got the probe almost working in the IDE. There is just one more hurdle to take, for which we'd need your help. Connection on Linux To connect to the probe's virtual COM-port on Linux, one needs to issue the gdb command: (gdb) target extended-remote /dev/ttyACM0 In your FAQ, you give a solution to provide a stable name to this virtual COM-port, like /dev/ttyBmpGdb . However, it's more problematic on Windows... Connection on Windows To connect to the probe's virtual COM-port on Windows, the command would look like: (gdb) target extended-remote \\.\COM10 However, the name of the COM-port is uknown beforehand. We cannot ask our users to look up the COM-port in the device manager and fill it in somewhere. We want it to work "out of the box". Is it possible to detect the virtual COM-port's name automatically through some Windows console command? Or perhaps a python command? Thank you very much for your help. Kind greetings, Kristof Mulier _______________________________________________ Blackmagicdebug-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: <kri...@te...> - 2019-09-08 13:17:24
|
Dear Black Magic developers, We are working on a new C/C++ IDE for programming microcontrollers. We've not yet launched the software, but you can have a sneak peak on our test website: https://test.embeetle.com We would like to support your open-source Black Magic probe in the IDE. Everything is well explained on your github page (https://github.com/blacksphere/blackmagic/wiki/Getting-Started) so we got the probe almost working in the IDE. There is just one more hurdle to take, for which we'd need your help. Connection on Linux To connect to the probe's virtual COM-port on Linux, one needs to issue the gdb command: (gdb) target extended-remote /dev/ttyACM0 In your FAQ, you give a solution to provide a stable name to this virtual COM-port, like /dev/ttyBmpGdb . However, it's more problematic on Windows... Connection on Windows To connect to the probe's virtual COM-port on Windows, the command would look like: (gdb) target extended-remote \\.\COM10 However, the name of the COM-port is uknown beforehand. We cannot ask our users to look up the COM-port in the device manager and fill it in somewhere. We want it to work "out of the box". Is it possible to detect the virtual COM-port's name automatically through some Windows console command? Or perhaps a python command? Thank you very much for your help. Kind greetings, Kristof Mulier |
From: Gareth M. <ga...@bl...> - 2018-09-17 03:06:28
|
Applied. Thank you. On Mon, Sep 17, 2018 at 2:27 PM, Nikolay Dimitrov <nik...@re...> wrote: > While scanning the USB bus for devices, stm32_scan() can find a device that it > doesn't have permissions to access it, dfu/usb class raises an exception and > stm32_scan() stops the scan completely. > > This fix resolves the scan issue, by allowing the scan loop to continue. > While at it, there are cosmetic fixes related with tabs/spaces and readability. > > Signed-off-by: Nikolay Dimitrov <nik...@re...> > --- > scripts/stm32_mem.py | 55 +++++++++++++++++++++++++++++++++++----------------- > 1 file changed, 37 insertions(+), 18 deletions(-) > > diff --git a/scripts/stm32_mem.py b/scripts/stm32_mem.py > index 732685c..805f248 100755 > --- a/scripts/stm32_mem.py > +++ b/scripts/stm32_mem.py > @@ -79,32 +79,45 @@ def stm32_manifest(dev): > sleep(status.bwPollTimeout / 1000.0) > if status.bState == dfu.STATE_DFU_MANIFEST: > break > + > def stm32_scan(args, test): > devs = dfu.finddevs() > + bmp_devs = [] > bmp = 0 > if not devs: > - if test == True: > - return > + if test == True: > + return > + > print "No DFU devices found!" > exit(-1) > > for dev in devs: > - try: > - dfudev = dfu.dfu_device(*dev) > - except: > - return 0 > + try: > + dfudev = dfu.dfu_device(*dev) > + except: > + # Exceptions are raised when current user doesn't have permissions > + # for the specified USB device, but the device scan needs to > + # continue > + continue > + > man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) > - if man == "Black Sphere Technologies": bmp = bmp + 1 > - if bmp == 0 : > - if test == True: > - return > + if man == "Black Sphere Technologies": > + bmp = bmp + 1 > + bmp_devs.append(dev) > + > + if bmp == 0: > + if test == True: > + return > + > print "No compatible device found\n" > exit(-1) > - if bmp > 1 and not args.serial_target : > - if test == True: > - return > + > + if bmp > 1 and not args.serial_target: > + if test == True: > + return > + > print "Found multiple devices:\n" > - for dev in devs: > + for dev in bmp_devs: > dfudev = dfu.dfu_device(*dev) > man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) > product = dfudev.handle.getString(dfudev.dev.iProduct, 96) > @@ -113,25 +126,31 @@ def stm32_scan(args, test): > print "Manufacturer:\t %s" % man > print "Product:\t %s" % product > print "Serial:\t\t %s\n" % serial_no > + > print "Select device with serial number!" > exit (-1) > > - for dev in devs: > + for dev in bmp_devs: > dfudev = dfu.dfu_device(*dev) > man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) > product = dfudev.handle.getString(dfudev.dev.iProduct, 96) > serial_no = dfudev.handle.getString(dfudev.dev.iSerialNumber, 30) > if args.serial_target: > - if man == "Black Sphere Technologies" and serial_no == args.serial_target: break > + if man == "Black Sphere Technologies" and serial_no == args.serial_target: > + break > else: > - if man == "Black Sphere Technologies": break > + if man == "Black Sphere Technologies": > + break > + > print "Device ID:\t %04x:%04x" % (dfudev.dev.idVendor, dfudev.dev.idProduct) > print "Manufacturer:\t %s" % man > print "Product:\t %s" % product > print "Serial:\t\t %s" % serial_no > - if args.serial_target and serial_no != args.serial_target: > + > + if args.serial_target and serial_no != args.serial_target: > print "Serial number doesn't match!\n" > exit(-2) > + > return dfudev > > if __name__ == "__main__": > -- > 2.11.0 > -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Nikolay D. <nik...@re...> - 2018-09-17 03:02:55
|
While scanning the USB bus for devices, stm32_scan() can find a device that it doesn't have permissions to access it, dfu/usb class raises an exception and stm32_scan() stops the scan completely. This fix resolves the scan issue, by allowing the scan loop to continue. While at it, there are cosmetic fixes related with tabs/spaces and readability. Signed-off-by: Nikolay Dimitrov <nik...@re...> --- scripts/stm32_mem.py | 55 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/scripts/stm32_mem.py b/scripts/stm32_mem.py index 732685c..805f248 100755 --- a/scripts/stm32_mem.py +++ b/scripts/stm32_mem.py @@ -79,32 +79,45 @@ def stm32_manifest(dev): sleep(status.bwPollTimeout / 1000.0) if status.bState == dfu.STATE_DFU_MANIFEST: break + def stm32_scan(args, test): devs = dfu.finddevs() + bmp_devs = [] bmp = 0 if not devs: - if test == True: - return + if test == True: + return + print "No DFU devices found!" exit(-1) for dev in devs: - try: - dfudev = dfu.dfu_device(*dev) - except: - return 0 + try: + dfudev = dfu.dfu_device(*dev) + except: + # Exceptions are raised when current user doesn't have permissions + # for the specified USB device, but the device scan needs to + # continue + continue + man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) - if man == "Black Sphere Technologies": bmp = bmp + 1 - if bmp == 0 : - if test == True: - return + if man == "Black Sphere Technologies": + bmp = bmp + 1 + bmp_devs.append(dev) + + if bmp == 0: + if test == True: + return + print "No compatible device found\n" exit(-1) - if bmp > 1 and not args.serial_target : - if test == True: - return + + if bmp > 1 and not args.serial_target: + if test == True: + return + print "Found multiple devices:\n" - for dev in devs: + for dev in bmp_devs: dfudev = dfu.dfu_device(*dev) man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) product = dfudev.handle.getString(dfudev.dev.iProduct, 96) @@ -113,25 +126,31 @@ def stm32_scan(args, test): print "Manufacturer:\t %s" % man print "Product:\t %s" % product print "Serial:\t\t %s\n" % serial_no + print "Select device with serial number!" exit (-1) - for dev in devs: + for dev in bmp_devs: dfudev = dfu.dfu_device(*dev) man = dfudev.handle.getString(dfudev.dev.iManufacturer, 30) product = dfudev.handle.getString(dfudev.dev.iProduct, 96) serial_no = dfudev.handle.getString(dfudev.dev.iSerialNumber, 30) if args.serial_target: - if man == "Black Sphere Technologies" and serial_no == args.serial_target: break + if man == "Black Sphere Technologies" and serial_no == args.serial_target: + break else: - if man == "Black Sphere Technologies": break + if man == "Black Sphere Technologies": + break + print "Device ID:\t %04x:%04x" % (dfudev.dev.idVendor, dfudev.dev.idProduct) print "Manufacturer:\t %s" % man print "Product:\t %s" % product print "Serial:\t\t %s" % serial_no - if args.serial_target and serial_no != args.serial_target: + + if args.serial_target and serial_no != args.serial_target: print "Serial number doesn't match!\n" exit(-2) + return dfudev if __name__ == "__main__": -- 2.11.0 |
From: Gareth M. <ga...@bl...> - 2018-04-08 23:20:56
|
If things are implemented correctly, SRST and TRST are independent signals, where TRST resets the debug logic, and SRST resets everything else. There is no need for the TRST signal in most cases, and it's often not available on microcontrollers. There is no TRST output from the BMP, and there is no pin for it on the Cortex debug connector. The soft-reset is used instead. SRST is implemented, and is useful to recover from situations where target firmware disables or remaps the JTAG pins, or goes to low power modes where debug is not available. There are some targets that have incorrectly connected SRST and TRST, so that asserting SRST also resets the debug logic. For these targets BMP will not drive SRST at all, and will only use a soft reset to reset the target. Regards, Gareth On Mon, Mar 19, 2018 at 3:08 AM, Kévin R. <bm...@ma...> wrote: > Hi, > > I have a question regarding my understanding of TRST and SRST as implemented in the BMP. > In my mind JTAG TRST is the reset line for the JTAG TAP (i.e. only resetting the JTAG related functions, but not the whole system), while SRST is the reset line for the system (resetting the complete board being debugged). > > In the source code (platform.h) nTRST is on PB1. This pin is also used for PWR_BR, which according to the schematic of BMPM2 is controlling Vcc (e.g. providing power to the target board). > This for me looks more like what SRST should be responsible for. > On the other hand SRST in the source code is on PA2. According to the schematic this is iRST, becoming xRST, RST, and finally tRST on the JTAG-10 connector. > This looks more like a TRST line. > > I've searched in the github issues, wiki, and mailing list, but couldn't find more information. > Am I overlooking some aspect or are the TRST and SRST definitions swapped in the source code and/or schematic? > > Also, in the jtagtap.c source code TRST is used on STM32 only if the hardware platform is 0, while it is always used for TM4C. Is this as intended? > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Kévin R. <bm...@ma...> - 2018-03-18 14:08:32
|
Hi, I have a question regarding my understanding of TRST and SRST as implemented in the BMP. In my mind JTAG TRST is the reset line for the JTAG TAP (i.e. only resetting the JTAG related functions, but not the whole system), while SRST is the reset line for the system (resetting the complete board being debugged). In the source code (platform.h) nTRST is on PB1. This pin is also used for PWR_BR, which according to the schematic of BMPM2 is controlling Vcc (e.g. providing power to the target board). This for me looks more like what SRST should be responsible for. On the other hand SRST in the source code is on PA2. According to the schematic this is iRST, becoming xRST, RST, and finally tRST on the JTAG-10 connector. This looks more like a TRST line. I've searched in the github issues, wiki, and mailing list, but couldn't find more information. Am I overlooking some aspect or are the TRST and SRST definitions swapped in the source code and/or schematic? Also, in the jtagtap.c source code TRST is used on STM32 only if the hardware platform is 0, while it is always used for TM4C. Is this as intended? |
From: Hynek S. <ec...@ce...> - 2017-08-09 06:15:23
|
Hi, I would like to use BlackMagicProbe for debug with this MCU. It is Cortex-M3 and uses JTAG. Unfortunately, it has strange cJTAG as default protocol and it has to be switched to regular JTAG first. Is there any way how to add such device to BlackMagicProbe? cJTAG uses TMS and TCK signals to go through JTAG states to communicate (see swcu117g.pdf, chapter 5, or directly 5.2.2) I'd like to try it but I don't know where to add this switching sequence... BR, Hynek |
From: Daniel B. <dan...@gm...> - 2017-08-03 19:04:04
|
Hi Paul, Thanks for your reply. After having read carefully this commit message and examine more in detail the code that's ok. Well done and I am very happy about Blackmagic Probe and the support. That would be nice that this information is in the README, at least in stlink folder. TH a lot !! And thank you. On 03.08.2017 19:43, Paul Fertser wrote: > Hello, > > On Thu, Aug 03, 2017 at 05:26:16PM +0200, Daniel Burnier wrote: >> I will start from f4discovery implementation >> but before that I would like understand for the >> stlink platform, the usage difference between >> blackmagic_dfu (DFU_MODE) and dfu_upgrade >> (UPD_MODE). > Please see commit message for 0c9d5d816639c2b4ebce2b234be52e6aac4275a7 > , it seems to explain it all nicely. > > HTH > |
From: Paul F. <fer...@gm...> - 2017-08-03 17:43:57
|
Hello, On Thu, Aug 03, 2017 at 05:26:16PM +0200, Daniel Burnier wrote: > I will start from f4discovery implementation > but before that I would like understand for the > stlink platform, the usage difference between > blackmagic_dfu (DFU_MODE) and dfu_upgrade > (UPD_MODE). Please see commit message for 0c9d5d816639c2b4ebce2b234be52e6aac4275a7 , it seems to explain it all nicely. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Daniel B. <dan...@gm...> - 2017-08-03 15:26:27
|
Hi, I'am porting BlackMagic Probe on an robotic platform using STM32F413 as debug probe (because having DFU on USB and doesn't needing to be programmed at first time) and as low level controller for the platform (power management, power up configurator for an USB UHB and a Power Delivery controller, ...). I will start from f4discovery implementation but before that I would like understand for the stlink platform, the usage difference between blackmagic_dfu (DFU_MODE) and dfu_upgrade (UPD_MODE). Thanks in advance and best regards. -- Daniel Burnier Tél : + 41 21 693 78 26 Fax : + 41 21 693 78 07 E-mail : Dan...@ep... Bureau : http://plan.epfl.ch/?room=ME.B3.30 |
From: Dave M. <da...@ma...> - 2017-05-04 07:36:26
|
The easiest way around this is to pre-sign the code. The utility attached will do that for you (BSD Licence). Regards DAVE On 30/04/2017 21:12, Bart Bilos wrote: > Hi all, > > I am toying around with the black magic probe and I got an official > version 2.0. I am using codeblocks as my IDE of choice together with > custom makefiles to make my executable. Debugging works fine but I > have added the compare-sections command after codeblocks attaches to > GDB but I get the mis-matched error. > > My development enviroment is partly ported from LPCxpresso and is > available here: > https://github.com/Squantor/lpc_81x_frame , just run make release and > should build the resultant .elf file. > > Here is an excerpt of the output log: > > [debug]>>>>>>cb_gdb: > [debug]> directory /home/abilos/projects/public/lpc_81x_frame/ > [debug]>>>>>>cb_gdb:Source directories searched: > /home/abilos/projects/public/lpc_81x_frame:$cdir:$cwd > [debug]> set remotebaud 115200 > [debug]>>>>>>cb_gdb: > [debug]> target extended-remote /dev/ttyBmpGdb > [debug]No symbol "remotebaud" in current context. > [debug]>>>>>>cb_gdb: > > Connected > > [debug]> monitor swdp_scan > [debug]Remote debugging using /dev/ttyBmpGdb > [debug]Target voltage: 3.3V > [debug]>>>>>>cb_gdb: > [debug]> attach 1 > [debug]Available Targets: > [debug]No. Att Driver > [debug] 1 LPC81x > [debug]>>>>>>cb_gdb:Attaching to program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf, > Remote target > [debug]> set mem inaccessible-by-default off > [debug]0x00000470 in delay_ms (ms=1000) at src/main.c:13 > [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:13:186:beg:0x470 > [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: > [debug]> set {int}0x40048000 = 2 > > At /home/abilos/projects/public/lpc_81x_frame/src/main.c:13 > > [debug]> set {int}0x40048000 = 2 > [debug]>>>>>>cb_gdb: > [debug]> load bin/debug/periph_blinky.elf > [debug]>>>>>>cb_gdb: > [debug]> compare-sections > [debug]Loading section .text, size 0x1080 lma 0x0 > [debug]Loading section .ARM.exidx, size 0x8 lma 0x1080 > [debug]Start address 0x148, load size 4232 > [debug]Transfer rate: 7 KB/sec, 705 bytes/write. > [debug]>>>>>>cb_gdb: > [debug]> start > [debug]the loaded file > [debug]Section .text, range 0x0 -- 0x1080: MIS-MATCHED! > [debug]Section .ARM.exidx, range 0x1080 -- 0x1088: matched. > [debug]>>>>>>cb_gdb: > [debug]> tty /dev/pts/12 > [debug]Temporary breakpoint 2 at 0x492: file src/main.c, line 18. > [debug]Starting program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf > [debug]Note: automatically using hardware breakpoints for read-only addresses. > [debug]Temporary breakpoint 2, main () at src/main.c:18 > [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 > [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: > > Temporary breakpoint 2 at 0x492: file src/main.c, line 18. > Starting program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf > Note: automatically using hardware breakpoints for read-only addresses. > Temporary breakpoint 2, main () at src/main.c:18 > /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 > > Here are the commands I input after codeblocks attaches to GDB: > monitor swdp_scan > attach 1 > set mem inaccessible-by-default off > set {int}0x40048000 = 2 > load bin/release/periph_blinky.elf > compare-sections > start > > I have added the set {int}0x40048000 = 2 as described in the wiki but > still get the problem. I have not encountered any problems with the > LPClink2 I used before with this board. The board is a small > breadboardable lpc812 board that has minimal components. > > The funny thing is, debugging works fine and the program runs without an issue. > > Anybody have any ideas? > > With kind regards, > > Bart Bilos > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: Gareth M. <ga...@bl...> - 2017-05-03 20:34:22
|
Hi Bart The first sector way fail verification because of the magic vector that needs to be inserted for the device to boot from flash. See https://github.com/blacksphere/blackmagic/blob/master/src/target/lpc_common.c#L140 Regards, Gareth On Sun, Apr 30, 2017 at 1:12 PM, Bart Bilos <squ...@gm...> wrote: > Hi all, > > I am toying around with the black magic probe and I got an official > version 2.0. I am using codeblocks as my IDE of choice together with > custom makefiles to make my executable. Debugging works fine but I > have added the compare-sections command after codeblocks attaches to > GDB but I get the mis-matched error. > > My development enviroment is partly ported from LPCxpresso and is > available here: > https://github.com/Squantor/lpc_81x_frame , just run make release and > should build the resultant .elf file. > > Here is an excerpt of the output log: > > [debug]>>>>>>cb_gdb: > [debug]> directory /home/abilos/projects/public/lpc_81x_frame/ > [debug]>>>>>>cb_gdb:Source directories searched: > /home/abilos/projects/public/lpc_81x_frame:$cdir:$cwd > [debug]> set remotebaud 115200 > [debug]>>>>>>cb_gdb: > [debug]> target extended-remote /dev/ttyBmpGdb > [debug]No symbol "remotebaud" in current context. > [debug]>>>>>>cb_gdb: > > Connected > > [debug]> monitor swdp_scan > [debug]Remote debugging using /dev/ttyBmpGdb > [debug]Target voltage: 3.3V > [debug]>>>>>>cb_gdb: > [debug]> attach 1 > [debug]Available Targets: > [debug]No. Att Driver > [debug] 1 LPC81x > [debug]>>>>>>cb_gdb:Attaching to program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf, > Remote target > [debug]> set mem inaccessible-by-default off > [debug]0x00000470 in delay_ms (ms=1000) at src/main.c:13 > [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:13:186:beg:0x470 > [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: > [debug]> set {int}0x40048000 = 2 > > At /home/abilos/projects/public/lpc_81x_frame/src/main.c:13 > > [debug]> set {int}0x40048000 = 2 > [debug]>>>>>>cb_gdb: > [debug]> load bin/debug/periph_blinky.elf > [debug]>>>>>>cb_gdb: > [debug]> compare-sections > [debug]Loading section .text, size 0x1080 lma 0x0 > [debug]Loading section .ARM.exidx, size 0x8 lma 0x1080 > [debug]Start address 0x148, load size 4232 > [debug]Transfer rate: 7 KB/sec, 705 bytes/write. > [debug]>>>>>>cb_gdb: > [debug]> start > [debug]the loaded file > [debug]Section .text, range 0x0 -- 0x1080: MIS-MATCHED! > [debug]Section .ARM.exidx, range 0x1080 -- 0x1088: matched. > [debug]>>>>>>cb_gdb: > [debug]> tty /dev/pts/12 > [debug]Temporary breakpoint 2 at 0x492: file src/main.c, line 18. > [debug]Starting program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf > [debug]Note: automatically using hardware breakpoints for read-only addresses. > [debug]Temporary breakpoint 2, main () at src/main.c:18 > [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 > [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: > > Temporary breakpoint 2 at 0x492: file src/main.c, line 18. > Starting program: > /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf > Note: automatically using hardware breakpoints for read-only addresses. > Temporary breakpoint 2, main () at src/main.c:18 > /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 > > Here are the commands I input after codeblocks attaches to GDB: > monitor swdp_scan > attach 1 > set mem inaccessible-by-default off > set {int}0x40048000 = 2 > load bin/release/periph_blinky.elf > compare-sections > start > > I have added the set {int}0x40048000 = 2 as described in the wiki but > still get the problem. I have not encountered any problems with the > LPClink2 I used before with this board. The board is a small > breadboardable lpc812 board that has minimal components. > > The funny thing is, debugging works fine and the program runs without an issue. > > Anybody have any ideas? > > With kind regards, > > Bart Bilos > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Bart B. <squ...@gm...> - 2017-04-30 20:12:43
|
Hi all, I am toying around with the black magic probe and I got an official version 2.0. I am using codeblocks as my IDE of choice together with custom makefiles to make my executable. Debugging works fine but I have added the compare-sections command after codeblocks attaches to GDB but I get the mis-matched error. My development enviroment is partly ported from LPCxpresso and is available here: https://github.com/Squantor/lpc_81x_frame , just run make release and should build the resultant .elf file. Here is an excerpt of the output log: [debug]>>>>>>cb_gdb: [debug]> directory /home/abilos/projects/public/lpc_81x_frame/ [debug]>>>>>>cb_gdb:Source directories searched: /home/abilos/projects/public/lpc_81x_frame:$cdir:$cwd [debug]> set remotebaud 115200 [debug]>>>>>>cb_gdb: [debug]> target extended-remote /dev/ttyBmpGdb [debug]No symbol "remotebaud" in current context. [debug]>>>>>>cb_gdb: Connected [debug]> monitor swdp_scan [debug]Remote debugging using /dev/ttyBmpGdb [debug]Target voltage: 3.3V [debug]>>>>>>cb_gdb: [debug]> attach 1 [debug]Available Targets: [debug]No. Att Driver [debug] 1 LPC81x [debug]>>>>>>cb_gdb:Attaching to program: /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf, Remote target [debug]> set mem inaccessible-by-default off [debug]0x00000470 in delay_ms (ms=1000) at src/main.c:13 [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:13:186:beg:0x470 [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: [debug]> set {int}0x40048000 = 2 At /home/abilos/projects/public/lpc_81x_frame/src/main.c:13 [debug]> set {int}0x40048000 = 2 [debug]>>>>>>cb_gdb: [debug]> load bin/debug/periph_blinky.elf [debug]>>>>>>cb_gdb: [debug]> compare-sections [debug]Loading section .text, size 0x1080 lma 0x0 [debug]Loading section .ARM.exidx, size 0x8 lma 0x1080 [debug]Start address 0x148, load size 4232 [debug]Transfer rate: 7 KB/sec, 705 bytes/write. [debug]>>>>>>cb_gdb: [debug]> start [debug]the loaded file [debug]Section .text, range 0x0 -- 0x1080: MIS-MATCHED! [debug]Section .ARM.exidx, range 0x1080 -- 0x1088: matched. [debug]>>>>>>cb_gdb: [debug]> tty /dev/pts/12 [debug]Temporary breakpoint 2 at 0x492: file src/main.c, line 18. [debug]Starting program: /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf [debug]Note: automatically using hardware breakpoints for read-only addresses. [debug]Temporary breakpoint 2, main () at src/main.c:18 [debug] /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 [debug]>>>>>>cb_gdb:>>>>>>cb_gdb: Temporary breakpoint 2 at 0x492: file src/main.c, line 18. Starting program: /home/abilos/projects/public/lpc_81x_frame/bin/debug/periph_blinky.elf Note: automatically using hardware breakpoints for read-only addresses. Temporary breakpoint 2, main () at src/main.c:18 /home/abilos/projects/public/lpc_81x_frame/src/main.c:18:235:beg:0x492 Here are the commands I input after codeblocks attaches to GDB: monitor swdp_scan attach 1 set mem inaccessible-by-default off set {int}0x40048000 = 2 load bin/release/periph_blinky.elf compare-sections start I have added the set {int}0x40048000 = 2 as described in the wiki but still get the problem. I have not encountered any problems with the LPClink2 I used before with this board. The board is a small breadboardable lpc812 board that has minimal components. The funny thing is, debugging works fine and the program runs without an issue. Anybody have any ideas? With kind regards, Bart Bilos |
From: Dave M. <da...@ma...> - 2017-04-01 22:44:39
|
So, first thing to do was to upgrade everything to latest versions....and that has made GDB debug with Eclipse _much_ more reliable. I hesitate to call it 100% yet, but only because I've only done limited testing. So far I've observed _no_ failures since upgrading everything, Proper testing will be next week when I replace my J-Link with BMP as my regular development probe..I'll post a follow up towards the back end of next week with the results of that. For reference I'm running; macOS Sierra Version 10.12.3 Eclipse IDE for C/C++ Developers Version: Neon.3 Release (4.6.3), Build id: 20170314-1500 C/C++ GDB Hardware Debugging 9.2.1.201703062208 Eclipse IDE for C/C++ Developers 4.6.3.20170314-1500 Eclipse Platform 4.6.3.v20170301-0400 This was all upgraded to via Help->Check for Updates on 31st March 2017. The gdb in use is GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs The Blackmagic build tested is from the bluepill branch on one of the horrid little STM32F103C8 boards which is working well within the limits of its capabilities. If anyone else observes problems drop me an email and we'll compare notes to figure out what's different between the two configurations. DAVE On 29/03/2017 01:15, Gareth McMullin wrote: > On Wed, Mar 29, 2017 at 12:13 PM, Dave Marples <da...@ma...> wrote: >> Has anyone seen hangs on disconnect with OSX 10.12? Symptom is that the >> port never fully closes at the end of a debug session and then can't be >> opened again for another one - it hangs in some sort of limbo state. > This sounds like the open call on the tty device is blocking in the > half-open state, but GDB would be killed by SIGKILL if this was the > case. > Can you confirm that you are using the /dev/cu.usbmodem device, and > not the /dev/tty.usbmodem device that is known to have this kind of > problem. > > Regards, > Gareth |
From: King K. <kin...@cu...> - 2017-04-01 09:27:10
|
please find attached the patch for the black magic firmware to add support for an additional platform, the Baite ST-Link V2 clone. compared to the other ST-Link V2 clone (in an aluminium case) this also offers UART. you can find a bit more documentation here: https://wiki.cuvoodoo.info/doku.php?id=jtag#black_magic_probe . feel free to add for more details or add the code to your repo. |
From: Piotr Esden-T. <pi...@es...> - 2017-03-29 07:28:06
|
As a data point. I use BMPM on MacOS 10.12 quite a lot and I am not experiencing lockups. By a lot I mean running gdb in a loop and flashing hundreds of boards using a gdb script. :) I am not sure how your setup differs from mine that you do experience them I use only the built in USB ports of my iMac Retina. Do you have a usb trace you can record that results in your lockup? Cheers, Piotr > On Mar 28, 2017, at 11:35 PM, Dave Marples <da...@ma...> wrote: > > Gareth, > > When I look at the libopencm3 usb code it looks like you were the > original cook, do you recognise the issue addressed in response #22 in > the thread I referenced? > > Regards > > DAVE > > > On 29/03/2017 01:15, Gareth McMullin wrote: >> On Wed, Mar 29, 2017 at 12:13 PM, Dave Marples <da...@ma...> wrote: >>> Has anyone seen hangs on disconnect with OSX 10.12? Symptom is that the >>> port never fully closes at the end of a debug session and then can't be >>> opened again for another one - it hangs in some sort of limbo state. >> This sounds like the open call on the tty device is blocking in the >> half-open state, but GDB would be killed by SIGKILL if this was the >> case. >> Can you confirm that you are using the /dev/cu.usbmodem device, and >> not the /dev/tty.usbmodem device that is known to have this kind of >> problem. >> >> Regards, >> Gareth > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: Dave M. <da...@ma...> - 2017-03-29 06:35:15
|
Gareth, When I look at the libopencm3 usb code it looks like you were the original cook, do you recognise the issue addressed in response #22 in the thread I referenced? Regards DAVE On 29/03/2017 01:15, Gareth McMullin wrote: > On Wed, Mar 29, 2017 at 12:13 PM, Dave Marples <da...@ma...> wrote: >> Has anyone seen hangs on disconnect with OSX 10.12? Symptom is that the >> port never fully closes at the end of a debug session and then can't be >> opened again for another one - it hangs in some sort of limbo state. > This sounds like the open call on the tty device is blocking in the > half-open state, but GDB would be killed by SIGKILL if this was the > case. > Can you confirm that you are using the /dev/cu.usbmodem device, and > not the /dev/tty.usbmodem device that is known to have this kind of > problem. > > Regards, > Gareth |