blackmagicdebug-devel Mailing List for Black Magic Debug Probe (Page 3)
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: Gareth M. <ga...@bl...> - 2015-04-13 01:29:24
|
Hi Uwe On Thu, Apr 2, 2015 at 10:12 AM, Uwe Bonnes <bo...@el...> wrote: > please consider appended patches. > 0001 and 0002 help portability, > 0003 adds target voltage detection to the stlink. Please submit these as Github pull requests. > 0004 and 0005 are for a local hardware I have to keep alive. I can also > keep as a local branch, but having it i master makes things easier for me. > I can also provide eagle design files for the stm32f3_if. It doesn't look to me like these add anything new or interesting. They're just more copies of the stm32 platform code. They are also out of date. I've cleaned up platform code since these copies were made. I'd rather keep them out of the main repo, unless they're really useful, or of general interest. Thanks and regards, Gareth 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: Gareth M. <ga...@bl...> - 2015-04-02 17:17:09
|
On Thu, Apr 2, 2015 at 5:30 AM, Uwe Bonnes <bo...@el...> wrote: > trying on a clean checkout from > https://github.com/blacksphere/blackmagic.git > with > gcc version 4.9.3 20150303 (release) [ARM/embedded-4_9-branch revision\ > 221220] (GNU Tools for ARM Embedded Processors) > I get: > > cortexm.c: In function 'cortexm_halt_wait': > cortexm.c:467:11: error: variable 'dhcsr' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] > uint32_t dhcsr = 0; > ^ > cc1: all warnings being treated as errors This warning is a false positive in this case, and may be ignored. I think making dhcsr volatile as you suggest is an acceptable way to suppress the warning. Building with -Werror was unintentionally committed, sorry. I'll correct this too. I haven't had this problem, but I'm using an older gcc. I'll upgrade my compiler and fix these issues tonight. Cheers, Gareth -- 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: Uwe B. <bo...@el...> - 2015-04-02 17:12:34
|
Hello again, please consider appended patches. 0001 and 0002 help portability, 0003 adds target voltage detection to the stlink. 0004 and 0005 are for a local hardware I have to keep alive. I can also keep as a local branch, but having it i master makes things easier for me. I can also provide eagle design files for the stm32f3_if. Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Uwe B. <bo...@el...> - 2015-04-02 17:06:34
|
>>>>> "Gareth" == Gareth McMullin <ga...@bl...> writes: Gareth> This warning is a false positive in this case, and may be Gareth> ignored. I think making dhcsr volatile as you suggest is an Gareth> acceptable way to suppress the warning. Building with -Werror Gareth> was unintentionally committed, sorry. I'll correct this too. Please consider keeping -Werror. I think this can help code quality. Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Uwe B. <bo...@el...> - 2015-04-02 12:31:10
|
Hello, trying on a clean checkout from https://github.com/blacksphere/blackmagic.git with gcc version 4.9.3 20150303 (release) [ARM/embedded-4_9-branch revision\ 221220] (GNU Tools for ARM Embedded Processors) I get: cortexm.c: In function 'cortexm_halt_wait': cortexm.c:467:11: error: variable 'dhcsr' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] uint32_t dhcsr = 0; ^ cc1: all warnings being treated as errors Using appended patch solved the problem: diff --git a/src/cortexm.c b/src/cortexm.c index ac4c549..ae1c59d 100644 --- a/src/cortexm.c +++ b/src/cortexm.c @@ -464,7 +464,7 @@ static int cortexm_halt_wait(target *t) ADIv5_AP_t *ap = adiv5_target_ap(t); struct cortexm_priv *priv = ap->priv; - uint32_t dhcsr = 0; + volatile uint32_t dhcsr = 0; volatile struct exception e; TRY_CATCH (e, EXCEPTION_ALL) { /* If this times out because the target is in WFI then It that the right solution? Thanks -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Gareth M. <ga...@bl...> - 2015-03-16 15:46:37
|
Hi everyone I've started working on a significant clean-up of the code base. When I'm happy with the structure of the internals, I'll do some work on new features. As a result of these changes there may be some breakage on the master branch. If you continue to use code from master and find problem, please create issues on Github. I have created a stable branch v1.6, which will be in maintenance mode. If no issues are reported on this it will become a stable v1.6 release. I have a Jenkins instance setup to build from master and v1.6 branches. The binary images and Windows updaters are installed here: http://blacksphere.co.nz/builds/stable/ http://blacksphere.co.nz/builds/ Jenkins will also build pull requests and mark the pull request as bad if there are error or warnings in the build. Finally, a Gitter channel has been setup for general discussion: https://gitter.im/blacksphere/blackmagic Regards, Gareth -- 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: Gareth M. <ga...@bl...> - 2015-02-18 19:15:25
|
Hi Stephen I can't think of an elegant way to solve this. The problem is inconsistency between GDB's provided syscalls and those defined by ARM for semihosting. There is no syscall in GDB for SYS_FLEN. ARM's SYS_SEEK only supports absolute positioning, so SEEK_SET is always passed up to GDB. GDB does provide stat/fstat calls, which could read the file's size, but it needs a buffer in target memory to put the result. ARM doesn't provide a stat call. It's nasty but it would be possible to have SYS_FLEN call GDB's stat, and intercept the memory write back to get the length. The problem could also be solved by adding non-standard semihosting calls. Regards, Gareth On Wed, Feb 11, 2015 at 3:49 PM, Stephen Dwyer <sc...@ua...> wrote: > Hello, > > I was trying to get some file I/O working over semihosting using BMPM and > ran into some problems when using fseek() related commands when trying to > find file length and also feof() or otherwise EOF related. I looked into the > semihosting code in newlib and found that when trying to seek using > SEEK_END, the semihosting sends a AngelSWI_Reason_FLen packet. Looking at > the blackmagic source, it appears that in cortexm.c, the FLen packet is not > supported > (https://github.com/blacksphere/blackmagic/blob/master/src/cortexm.c#L914). > > I played around a bit and tried to call Flseek() with SEEK_END at offset 0, > and it does not seem to work at all... so I guess this is why it isn't > supported. > > I would love to know any details on this, and whether getting some of these > file access features working would be possible? Right now I have to do an > ugly workaround where I manually pass in the file length to my program, > which works, but I would really like to make it nicer. > > Any feedback would be appreciated! > > Thanks, > -Stephen Dwyer > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > 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: Stephen D. <sc...@ua...> - 2015-02-11 23:49:25
|
Hello, I was trying to get some file I/O working over semihosting using BMPM and ran into some problems when using fseek() related commands when trying to find file length and also feof() or otherwise EOF related. I looked into the semihosting code in newlib and found that when trying to seek using SEEK_END, the semihosting sends a AngelSWI_Reason_FLen packet. Looking at the blackmagic source, it appears that in cortexm.c, the FLen packet is not supported ( https://github.com/blacksphere/blackmagic/blob/master/src/cortexm.c#L914). I played around a bit and tried to call Flseek() with SEEK_END at offset 0, and it does not seem to work at all... so I guess this is why it isn't supported. I would love to know any details on this, and whether getting some of these file access features working would be possible? Right now I have to do an ugly workaround where I manually pass in the file length to my program, which works, but I would really like to make it nicer. Any feedback would be appreciated! Thanks, -Stephen Dwyer |
From: Uwe B. <bo...@el...> - 2014-12-18 10:51:29
|
Argh, I should have compiled. Please use the patchset appended here. -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From 3349f8e6fcf785500696f7e33585137042685853 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Thu, 18 Dec 2014 11:12:09 +0100 Subject: stm32f4.c: Add STM32F411 ID. --- libopencm3 | 2 +- src/stm32f4.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) mode change 160000 => 120000 libopencm3 diff --git a/libopencm3 b/libopencm3 deleted file mode 160000 index 67242de..0000000 --- a/libopencm3 +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 67242de60dec0227739cd549e8a78e1a3c15dbf5 diff --git a/libopencm3 b/libopencm3 new file mode 120000 index 0000000..e5a987e --- /dev/null +++ b/libopencm3 @@ -0,0 +1 @@ +../libopencm3/libopencm3 \ No newline at end of file diff --git a/src/stm32f4.c b/src/stm32f4.c index 892af41..4f27859 100644 --- a/src/stm32f4.c +++ b/src/stm32f4.c @@ -170,8 +170,9 @@ bool stm32f4_probe(struct target_s *target) case 0x411: /* Documented to be 0x413! This is what I read... */ case 0x413: /* F407VGT6 */ case 0x419: /* 427/437 */ - case 0x423: /* F401 */ - case 0x433: /* F401RET6U */ + case 0x423: /* F401 B/C RM0368 Rev.3 */ + case 0x431: /* F411 RM0383 Rev.4 */ + case 0x433: /* F401 D/E RM0368 Rev.3 */ target->xml_mem_map = stm32f4_xml_memory_map; target->driver = stm32f4_driver_str; target->flash_erase = stm32f4_flash_erase; -- 1.8.4.5 >From e3cea739f7e73a435c1de82f4b334005cd09ab52 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Wed, 25 Jun 2014 16:53:01 +0200 Subject: stm32l1: Add more idcodes. --- src/stm32l1.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/stm32l1.c b/src/stm32l1.c index 873d9b9..0472885 100644 --- a/src/stm32l1.c +++ b/src/stm32l1.c @@ -91,9 +91,12 @@ bool stm32l1_probe(struct target_s *target) idcode = adiv5_ap_mem_read(adiv5_target_ap(target), STM32L1_DBGMCU_IDCODE); switch(idcode & 0xFFF) { - case 0x416: /* Medium density */ - case 0x427: /* Medium+ density*/ - case 0x436: /* Medium+/High density */ + case 0x416: /* CAT. 1 device */ + case 0x429: /* CAT. 2 device */ + case 0x427: /* CAT. 3 device */ + case 0x436: /* CAT. 4 device */ + case 0x437: /* CAT. 5 device */ + target->idcode = idcode & 0xFFF; target->driver = stm32l1_driver_str; target->xml_mem_map = stm32l1_xml_memory_map; target->flash_erase = stm32l1_flash_erase; -- 1.8.4.5 >From cffe3826817822d71afde06095bc99a7d0c6e596 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Thu, 18 Dec 2014 11:24:44 +0100 Subject: stm32f1.c: Add more STM32F0 IDs. --- src/stm32f1.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/stm32f1.c b/src/stm32f1.c index 237135f..d02a26d 100644 --- a/src/stm32f1.c +++ b/src/stm32f1.c @@ -59,8 +59,10 @@ static const char stm32f1_driver_str[] = "STM32, Medium density."; static const char stm32hd_driver_str[] = "STM32, High density."; static const char stm32f3_driver_str[] = "STM32F3xx"; static const char stm32f03_driver_str[] = "STM32F03x"; +static const char stm32f04_driver_str[] = "STM32F04x"; static const char stm32f05_driver_str[] = "STM32F05x"; static const char stm32f07_driver_str[] = "STM32F07x"; +static const char stm32f09_driver_str[] = "STM32F09x"; static const char stm32f1_xml_memory_map[] = "<?xml version=\"1.0\"?>" /* "<!DOCTYPE memory-map " @@ -192,19 +194,27 @@ bool stm32f1_probe(struct target_s *target) target->idcode = adiv5_ap_mem_read(adiv5_target_ap(target), DBGMCU_IDCODE_F0) & 0xfff; switch(target->idcode) { - case 0x444: /* STM32F03 */ - case 0x440: /* STM32F05 */ - case 0x448: /* STM32F07 */ + case 0x444: /* STM32F03 RM0091 Rev.7 */ + case 0x445: /* STM32F04 RM0091 Rev.7 */ + case 0x440: /* STM32F05 RM0091 Rev.7 */ + case 0x448: /* STM32F07 RM0091 Rev.7 */ + case 0x442: /* STM32F09 RM0091 Rev.7 */ switch(target->idcode) { case 0x444: /* STM32F03 */ target->driver = stm32f03_driver_str; break; + case 0x445: /* STM32F04 */ + target->driver = stm32f04_driver_str; + break; case 0x440: /* STM32F05 */ target->driver = stm32f05_driver_str; break; case 0x448: /* STM32F07 */ target->driver = stm32f07_driver_str; break; + case 0x442: /* STM32F09 */ + target->driver = stm32f09_driver_str; + break; } target->xml_mem_map = stm32f1_xml_memory_map; target->flash_erase = stm32md_flash_erase; -- 1.8.4.5 |
From: Uwe B. <bo...@el...> - 2014-12-18 10:41:02
|
I found another patch on my tree... -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From f81b0bfd1ca191253ad57e8456ac628e780ed0ec Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Wed, 25 Jun 2014 16:53:01 +0200 Subject: stm32l1: Add more idcodes. --- src/stm32l1.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/stm32l1.c b/src/stm32l1.c index 873d9b9..0472885 100644 --- a/src/stm32l1.c +++ b/src/stm32l1.c @@ -91,9 +91,12 @@ bool stm32l1_probe(struct target_s *target) idcode = adiv5_ap_mem_read(adiv5_target_ap(target), STM32L1_DBGMCU_IDCODE); switch(idcode & 0xFFF) { - case 0x416: /* Medium density */ - case 0x427: /* Medium+ density*/ - case 0x436: /* Medium+/High density */ + case 0x416: /* CAT. 1 device */ + case 0x429: /* CAT. 2 device */ + case 0x427: /* CAT. 3 device */ + case 0x436: /* CAT. 4 device */ + case 0x437: /* CAT. 5 device */ + target->idcode = idcode & 0xFFF; target->driver = stm32l1_driver_str; target->xml_mem_map = stm32l1_xml_memory_map; target->flash_erase = stm32l1_flash_erase; -- 1.8.4.5 |
From: Uwe B. <bo...@el...> - 2014-12-18 10:34:25
|
Hello, appended patches add the F411 and F04x and F09x ids. Please consider applying. -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From 3349f8e6fcf785500696f7e33585137042685853 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Thu, 18 Dec 2014 11:12:09 +0100 Subject: stm32f4.c: Add STM32F411 ID. --- libopencm3 | 2 +- src/stm32f4.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) mode change 160000 => 120000 libopencm3 diff --git a/libopencm3 b/libopencm3 deleted file mode 160000 index 67242de..0000000 --- a/libopencm3 +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 67242de60dec0227739cd549e8a78e1a3c15dbf5 diff --git a/libopencm3 b/libopencm3 new file mode 120000 index 0000000..e5a987e --- /dev/null +++ b/libopencm3 @@ -0,0 +1 @@ +../libopencm3/libopencm3 \ No newline at end of file diff --git a/src/stm32f4.c b/src/stm32f4.c index 892af41..4f27859 100644 --- a/src/stm32f4.c +++ b/src/stm32f4.c @@ -170,8 +170,9 @@ bool stm32f4_probe(struct target_s *target) case 0x411: /* Documented to be 0x413! This is what I read... */ case 0x413: /* F407VGT6 */ case 0x419: /* 427/437 */ - case 0x423: /* F401 */ - case 0x433: /* F401RET6U */ + case 0x423: /* F401 B/C RM0368 Rev.3 */ + case 0x431: /* F411 RM0383 Rev.4 */ + case 0x433: /* F401 D/E RM0368 Rev.3 */ target->xml_mem_map = stm32f4_xml_memory_map; target->driver = stm32f4_driver_str; target->flash_erase = stm32f4_flash_erase; -- 1.8.4.5 >From 3518dad5c14a96311380b9b6f700733e9ff2fbb3 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Thu, 18 Dec 2014 11:24:44 +0100 Subject: stm32f1.c: Add more STM32F0 IDs. --- src/stm32f1.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/stm32f1.c b/src/stm32f1.c index 237135f..8aa69ea 100644 --- a/src/stm32f1.c +++ b/src/stm32f1.c @@ -59,8 +59,10 @@ static const char stm32f1_driver_str[] = "STM32, Medium density."; static const char stm32hd_driver_str[] = "STM32, High density."; static const char stm32f3_driver_str[] = "STM32F3xx"; static const char stm32f03_driver_str[] = "STM32F03x"; +static const char stm32f05_driver_str[] = "STM32F04x"; static const char stm32f05_driver_str[] = "STM32F05x"; static const char stm32f07_driver_str[] = "STM32F07x"; +static const char stm32f09_driver_str[] = "STM32F09x"; static const char stm32f1_xml_memory_map[] = "<?xml version=\"1.0\"?>" /* "<!DOCTYPE memory-map " @@ -192,19 +194,27 @@ bool stm32f1_probe(struct target_s *target) target->idcode = adiv5_ap_mem_read(adiv5_target_ap(target), DBGMCU_IDCODE_F0) & 0xfff; switch(target->idcode) { - case 0x444: /* STM32F03 */ - case 0x440: /* STM32F05 */ - case 0x448: /* STM32F07 */ + case 0x444: /* STM32F03 RM0091 Rev.7 */ + case 0x445: /* STM32F04 RM0091 Rev.7 */ + case 0x440: /* STM32F05 RM0091 Rev.7 */ + case 0x448: /* STM32F07 RM0091 Rev.7 */ + case 0x442: /* STM32F09 RM0091 Rev.7 */ switch(target->idcode) { case 0x444: /* STM32F03 */ target->driver = stm32f03_driver_str; break; + case 0x445: /* STM32F04 */ + target->driver = stm32f04_driver_str; + break; case 0x440: /* STM32F05 */ target->driver = stm32f05_driver_str; break; case 0x448: /* STM32F07 */ target->driver = stm32f07_driver_str; break; + case 0x442: /* STM32F09 */ + target->driver = stm32f09_driver_str; + break; } target->xml_mem_map = stm32f1_xml_memory_map; target->flash_erase = stm32md_flash_erase; -- 1.8.4.5 |
From: Liam S. <li...@st...> - 2014-11-11 15:39:54
|
OK, sounds good - thanks for the response, and buffering suggestion. Cheers, Liam On Mon, Nov 10, 2014, at 09:34 PM, Paul Fertser wrote: > Hi, > > On Fri, Nov 07, 2014 at 05:21:51PM -0800, Liam Staskawicz wrote: > > Is is possible to adjust (increase) the semihosting transfer rate? I haven't > > tested what the current default is, but on my STM32F1-based project, I've > > noticed it's quite slow, which makes a few debugging scenarios a bit more > > difficult than would be ideal. > > As was already answered, the rate is not adjustable as there's no rate > present at all. Each time the target wants to perform a semihosting > operation it stops on a breakpoint, the debugger notices it, inspects > the reason and acts accordingly. The operation itself usually involves > some RAM transfer and that's quite fast for most scenarious. > > That said, there's still one simple trick that in some cases helps a > lot. By default stdout is line-buffered so it results in one slow > semi-hosting call per every output line. If you want to output several > lines one-by-one as fast as possible, then set stdout to a fully > buffered mode with setvbuf() and then call fflush() at the point you > really need the buffered data transferred. > > HTH > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... |
From: Paul F. <fer...@gm...> - 2014-11-11 05:34:26
|
Hi, On Fri, Nov 07, 2014 at 05:21:51PM -0800, Liam Staskawicz wrote: > Is is possible to adjust (increase) the semihosting transfer rate? I haven't > tested what the current default is, but on my STM32F1-based project, I've > noticed it's quite slow, which makes a few debugging scenarios a bit more > difficult than would be ideal. As was already answered, the rate is not adjustable as there's no rate present at all. Each time the target wants to perform a semihosting operation it stops on a breakpoint, the debugger notices it, inspects the reason and acts accordingly. The operation itself usually involves some RAM transfer and that's quite fast for most scenarious. That said, there's still one simple trick that in some cases helps a lot. By default stdout is line-buffered so it results in one slow semi-hosting call per every output line. If you want to output several lines one-by-one as fast as possible, then set stdout to a fully buffered mode with setvbuf() and then call fflush() at the point you really need the buffered data transferred. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Gareth M. <ga...@bl...> - 2014-11-11 01:55:06
|
Hi Liam Sorry, it is not possible to control the transfer rate when semihosting. If you require high throughput, it would be better to use another interface for your IO. Regards, Gareth On Fri, Nov 7, 2014 at 5:21 PM, Liam Staskawicz <li...@st...> wrote: > Hello! > > Is is possible to adjust (increase) the semihosting transfer rate? I haven't > tested what the current default is, but on my STM32F1-based project, I've > noticed it's quite slow, which makes a few debugging scenarios a bit more > difficult than would be ideal. > > I haven't had much googling luck - any tips? > > Thanks, > Liam > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > _______________________________________________ > 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: Liam S. <li...@st...> - 2014-11-08 01:38:00
|
Hello! Is is possible to adjust (increase) the semihosting transfer rate? I haven't tested what the current default is, but on my STM32F1-based project, I've noticed it's quite slow, which makes a few debugging scenarios a bit more difficult than would be ideal. I haven't had much googling luck - any tips? Thanks, Liam |
From: Gareth M. <ga...@bl...> - 2014-09-27 10:05:24
|
On Fri, Sep 26, 2014 at 12:19 AM, Uwe Bonnes <bo...@el...> wrote: > I have my NutOS applications on STM32 configured to use WFI in the Idle > loop. Debugging programs works fine with Blackmagic. Now I try to debug a > NutOS application on a F429 Discovery board with the STLink not reprogrammed > to blackmagic, but still the STLink as delivered. I use openocd git head and > start openocd like: > ../src/openocd -s . -f ./board/stm32f429discovery.cfg > > The console fills up with > Error: jtag status contains invalid mode value - communication failure > Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms > Info : Previous state query failed, trying to reconnect > Polling target stm32f4x.cpu succeeded again, trying to reexamine When the core is in WFI, all DP transactions return a WAIT response indicating that the request has not yet completed. This is not a communication failure. It's normally not possible for the the debugger to interrupt the core when it's in WFI. Some implementations provide a way to work around this, like the DBGMCU_CR in STM32. In most cases the core doesn't spend a long time in WFI, so BMP just retries for a while, if the core receives an interrupt, it wakes up and halts. If no interrupt is received BMP will eventually give up and report SIGLOST. Cheers, Gareth -- 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: Uwe B. <bo...@el...> - 2014-09-25 12:19:43
|
Hello, I have my NutOS applications on STM32 configured to use WFI in the Idle loop. Debugging programs works fine with Blackmagic. Now I try to debug a NutOS application on a F429 Discovery board with the STLink not reprogrammed to blackmagic, but still the STLink as delivered. I use openocd git head and start openocd like: ../src/openocd -s . -f ./board/stm32f429discovery.cfg The console fills up with Error: jtag status contains invalid mode value - communication failure Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms Info : Previous state query failed, trying to reconnect Polling target stm32f4x.cpu succeeded again, trying to reexamine http://openocd.sourceforge.net/doc/html/OpenOCD-Project-Setup.html has some remarks with regard to the WFI instruction, but I don't understand why blackmagic doesn't have that problem. Having to disable WFI for debug builds also collides with the concept of NutOS as a library, as this requires rebuilding the library for debug and production builds of the user code. http://uttx.org/doku.php?id=wiki:howtos:jtag-debugging talks about having to set DBGMCU_CR_STANDBY. I wonder why I do not see a write to DBGMCU_CR in blackmagic and also wonder if setting DBGMCU_CR isn't a task for the STM32 startup code in Openocd. Thanks -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Uwe B. <bo...@el...> - 2014-09-25 09:34:54
|
>>>>> "Gareth" == Gareth McMullin <ga...@bl...> writes: Gareth> I didn't realise there is a mechanism to query symbol Gareth> information from GDB, so I was under the impression that it Gareth> would require parsing the ELF binary to find this information. Gareth> I'll look into this. There will need to be some generic Gareth> mechanism for handling multiple threads and RTOS specific Gareth> implementation for each supported RTOS. I was able to see the "qSymbol::" message and a reply for my or better blackmagics "qSymbol:nutThreadlist" query after some hacking. I noticed however that only a gdb "file" command triggered the "qSymbol::" readiness message. A sequence "arm-non-eabi gdb <file.elf>" "tar ext /dev/ttyACMx" "mon s" "attach 1" didn't trigger the "qSymbol::"gdb readiness message. Only "file <file>.elf" after the sequence above triggered the gdb-message. This is unhandy, as gdb asks for confirmation to load a new file. Is this indented gdb behaviour or a gdb flaw? Gareth> I'm using ChibiOS in some projects, and I agree this would be a Gareth> useful feature. Looking what I did in the hack and at the openocd/src/rtos code, I saw many similarities. And that a lot is needed to get things working. To not have two loose ends (debugger and thread code), I intend, as time allows, to start with adding NutOs to OpenOCD and test with an unmodified Stlink on a discovery board. Cheers -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Gareth M. <ga...@bl...> - 2014-09-25 00:44:00
|
Hi On Wed, Sep 24, 2014 at 11:08 PM, Paul Fertser <fer...@gm...> wrote: > On Tue, Sep 23, 2014 at 07:02:48PM +0200, Uwe Bonnes wrote: >> However attaching to a running program, I mostly catch the controller >> sleeping and so I only see the idle thread. Asking on the NutOS list about >> gdb and threads, Openocd was soon mentioned and I already had a look at the >> OpenOCD src/rtos directory. > > Basically, the way it's implemented in openocd currently requires knowledge of > layout of internal structures describing tasks but doesn't require knowledge of > particular start offsets for those structures. The deal is that openocd asks > gdb about the address where some structure lies in the current project and so > can get e.g. the pointer to the first element in a linked list or to a fixed > size array (whatever is used in the particular scheduler). But there's no way > openocd (or BMP) can ask gdb to tell it an offset of a particular field inside > a structure, and thus it must be known at openocd/bmp compile time (or some > additional configuration mechanism needs to be implemented). I didn't realise there is a mechanism to query symbol information from GDB, so I was under the impression that it would require parsing the ELF binary to find this information. I'll look into this. There will need to be some generic mechanism for handling multiple threads and RTOS specific implementation for each supported RTOS. I'm using ChibiOS in some projects, and I agree this would be a useful feature. Cheers, Gareth -- 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: Matt L. <dp...@gm...> - 2014-09-24 11:24:07
|
I would also be interested in RTOS support, I just got a BMP I’ve not had much chance to play yet but I’ll be using it to help debug a FreeRTOS based project Matt > On 24 Sep 2014, at 12:08, Paul Fertser <fer...@gm...> wrote: > > Hi, > > On Tue, Sep 23, 2014 at 07:02:48PM +0200, Uwe Bonnes wrote: >> However attaching to a running program, I mostly catch the controller >> sleeping and so I only see the idle thread. Asking on the NutOS list about >> gdb and threads, Openocd was soon mentioned and I already had a look at the >> OpenOCD src/rtos directory. > > Basically, the way it's implemented in openocd currently requires knowledge of > layout of internal structures describing tasks but doesn't require knowledge of > particular start offsets for those structures. The deal is that openocd asks > gdb about the address where some structure lies in the current project and so > can get e.g. the pointer to the first element in a linked list or to a fixed > size array (whatever is used in the particular scheduler). But there's no way > openocd (or BMP) can ask gdb to tell it an offset of a particular field inside > a structure, and thus it must be known at openocd/bmp compile time (or some > additional configuration mechanism needs to be implemented). > > Also, when working with threads, it might be useful to have some profiling > support, openocd provides a universally working hack when it samples PC every > now and then and outputs a file in gprof format. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Blackmagicdebug-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blackmagicdebug-devel |
From: Paul F. <fer...@gm...> - 2014-09-24 11:09:05
|
Hi, On Tue, Sep 23, 2014 at 07:02:48PM +0200, Uwe Bonnes wrote: > However attaching to a running program, I mostly catch the controller > sleeping and so I only see the idle thread. Asking on the NutOS list about > gdb and threads, Openocd was soon mentioned and I already had a look at the > OpenOCD src/rtos directory. Basically, the way it's implemented in openocd currently requires knowledge of layout of internal structures describing tasks but doesn't require knowledge of particular start offsets for those structures. The deal is that openocd asks gdb about the address where some structure lies in the current project and so can get e.g. the pointer to the first element in a linked list or to a fixed size array (whatever is used in the particular scheduler). But there's no way openocd (or BMP) can ask gdb to tell it an offset of a particular field inside a structure, and thus it must be known at openocd/bmp compile time (or some additional configuration mechanism needs to be implemented). Also, when working with threads, it might be useful to have some profiling support, openocd provides a universally working hack when it samples PC every now and then and outputs a file in gprof format. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Uwe B. <bo...@el...> - 2014-09-23 17:45:35
|
Dear Gareth, I mostly use NutOS http://www.ethernut.de/ on STM32 for my projects. NutOS provides Threads and cooperative multitasking. For debugging my projects, I use Blackmagic. However attaching to a running program, I mostly catch the controller sleeping and so I only see the idle thread. Asking on the NutOS list about gdb and threads, Openocd was soon mentioned and I already had a look at the OpenOCD src/rtos directory. What would be needed to teach blackmagic (rt)os and especially NutOsthreads? How does the effort compare to teach OpenOCD NutOs Threads? Is the support needed inside NutOS the same for using a blackmagic remote gdb session or OpenOCD? Thanks -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Gareth M. <ga...@bl...> - 2014-07-31 11:16:24
|
Hi everyone Just to let you know, I've moved the upstream repository to: https://github.com/blacksphere/blackmagic Github redirects are in place from the old location, but it is a good idea to update your links. Because Sourceforge turned off MediaWiki, I've copied most of the contents over to Github too: https://github.com/blacksphere/blackmagic/wiki I'll do some work on this to get it up to date as time allows. I hope this isn't too much of a disruption. Regards, Gareth -- 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: Liam S. <li...@st...> - 2014-07-10 14:38:33
|
Hi Uwe, Yes, after some more searching I discovered the 'mon connect_srst enable' command and was able to recover. Thanks! Liam On Thu, Jul 10, 2014, at 01:42 AM, Uwe Bonnes wrote: > >>>>> "Liam" == Liam Staskawicz <li...@st...> writes: > > Liam> Hi, I'm just getting started with the BMP and had been using it > Liam> successfully for some time, until I managed to get my board > into a > Liam> state in which I can no longer attach to it. The output: > > Liam> (gdb) mon jtag_scan Target voltage: 3.2V Device IR Len IDCODE > Liam> Description 040x3BA00477 ARM Limited: ADIv5 JTAG-DP port. > Liam> 150x16410041 ST Microelectronics: STM32, Medium density. > > Liam> Available Targets: No. Att Driver 1 STM32, Medium density. > (gdb) > Liam> att 1 Attaching to program: myproj.elf, Remote target Attaching > to > Liam> Remote target failed > > Liam> I believe the MCU is sitting in a WFI instruction. > > Liam> The jtag_scan does not succeed unless I hold the board in > reset, > Liam> but the attach command fails in all cases I've tried so far. > > Liam> This doesn't seem likely to be a BMP issue, but does anybody > have > Liam> any hints on how to proceed? > > Do you have a recent firmware? In May 13 Paul Fertser added code to > attach > to a sleeping target by pulling SRST. Is SRST connected at all? > > Bye > > -- > Uwe Bonnes bo...@el... > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
From: Uwe B. <bo...@el...> - 2014-07-10 08:54:57
|
>>>>> "Liam" == Liam Staskawicz <li...@st...> writes: Liam> Hi, I'm just getting started with the BMP and had been using it Liam> successfully for some time, until I managed to get my board into a Liam> state in which I can no longer attach to it. The output: Liam> (gdb) mon jtag_scan Target voltage: 3.2V Device IR Len IDCODE Liam> Description 040x3BA00477 ARM Limited: ADIv5 JTAG-DP port. Liam> 150x16410041 ST Microelectronics: STM32, Medium density. Liam> Available Targets: No. Att Driver 1 STM32, Medium density. (gdb) Liam> att 1 Attaching to program: myproj.elf, Remote target Attaching to Liam> Remote target failed Liam> I believe the MCU is sitting in a WFI instruction. Liam> The jtag_scan does not succeed unless I hold the board in reset, Liam> but the attach command fails in all cases I've tried so far. Liam> This doesn't seem likely to be a BMP issue, but does anybody have Liam> any hints on how to proceed? Do you have a recent firmware? In May 13 Paul Fertser added code to attach to a sleeping target by pulling SRST. Is SRST connected at all? Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |