Black Magic Probe on an stm32f103c8

Ok

I will try again on an F1 to prove its not some other problem.
Which could be the case as I’m using a GD32 board, but all I changed was the line in the source that specified it had a 12mhz crystal instead of the 8mhz on the normal SMT32F103 boards.

i.e I’m still running it at 72Mhz and didnt go the whole way and changed the USB prescaler and push it up to 120MHz.

It definitely connected to the F1, and gdb shows all the signs that its working, scan of devices recognizes it as a CortexM0 device etc and attaches OK.

I do get some notices / warnings e.g. cant read target voltage, and a few other messages, but I get the same sort of thing using OpenOCD and an STLink adaptor to flash the same module, and it does flash OK with STLink.

I guess I could try running the Texane STLink server and see if GDB can flash using that method, but I’d really like to use the BMP as it provides serial as well as SWD, and also its self contained, i.e you don’t additionally need the OpenOCD binaries ( and as yet I cant find a way to script OpenOCD to do the upload unless I pipe a script in via Telnet ( which gets very messy)

As I rebuilt from your github sources less than a week ago ( so I could use the GD32) it should all be up to date with the nRF51 stuff, but I guess I could post an issue / question on the main blacksphere repo to see if there are any known nrf51 issues.

If you use the gdb command ‘monitor help’, does an option show up for mass erasing the NRF51? It should. Of you course you have to do this after you have done the ‘monitor swdp_scan’ and the ‘attach 1’

FWIW, here’s example output with an STM32F103:

(gdb) tar ext /dev/cu.usbmodemD5D4C5E1
Remote debugging using /dev/cu.usbmodemD5D4C5E1
(gdb) mon swdp
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 STM32F1 medium density
(gdb) at 1
Attaching to Remote target
0x080013ac in ?? ()
(gdb) mon help
General commands:
version -- Display firmware version info
help -- Display help for monitor commands
jtag_scan -- Scan JTAG chain for devices
swdp_scan -- Scan SW-DP for devices
targets -- Display list of available targets
morse -- Display morse error message
connect_srst -- Configure connect under SRST: (enable|disable)
ARM Cortex-M specific commands:
vector_catch -- Catch exception vectors
STM32 LD/MD specific commands:
erase_mass -- Erase entire flash memory
option -- Manipulate option bytes
(gdb)

RogerClark wrote:I do get some notices / warnings e.g. cant read target voltage, and a few other messages, but I get the same sort of thing using OpenOCD and an STLink adaptor to flash the same module, and it does flash OK with STLink.

I actually had the voltage reading coded and then ripped it out as you needed to provide some external circuitry. It isn’t required so I tanked it.

No worries.

FYI.

I just modified the STM32 upload pattern, and just removed the code that displayed the memory locations, and to solve the COM issue i had with the double digit COM port issue

tools.bmp_upload.upload.pattern="{path}{cmd}" -cd "{build.path}" -b {upload.speed} {upload.verbose} -ex "set debug remote 0" -ex "set target-async off" -ex "set remotetimeout 60" -ex "set mem inaccessible-by-default off" -ex "set confirm off" -ex "set height 0" -ex "target extended-remote \\.\{serial.port}" -ex "monitor swdp_scan" -ex "attach 1" -ex "file {build.project_name}.elf" -ex "load" -ex "tbreak main" -ex "run" -ex "echo \n\n\nUpload finished!" -ex "quit"


Can you post the exact output? Most useful would be doing it in stages by hand at first from the command line

0.) launch arm-none-eabi-gdb

1.) Connect .. make sure you are connected
target extended-remote \\.COM9
monitor swdp_scan
attach 1

2.) Examine memory where you expect to write
(gdb) x/4x 0x20000000

look to see if the memory where you are going to write, address 0x20000000 in the case above, is empty (0xffffffff)

3.) Try erasing memory
(gdb) monitor erase_mass

go back to step 2 and see if it is erased

Turning it up to 11 might be a little too adventurous to start with.

-rick

I dont think mass_erase is supported

But I’ll try again just be sure

It should be:

https://github.com/RickKimball/blackmag … rf51.c#L44
https://github.com/RickKimball/blackmag … f51.c#L208

umm

I’m sure that didnt work last time I tried it

Perhaps it doesnt know its an nRF51

How do I tell GDB what process it is, perhaps the version info in the chips don’t match what BMP / GDB expect ? I know there are multiple versions of nRF51 though I’m not sure what the AAxx letters at the end of the part number actually mean.

Its saying that mass_erase is not supported

GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140228-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) target extended-remote \\.\COM38
Remote debugging using \\.\COM38
(gdb) monitor swdp_scan
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 ARM Cortex-M
(gdb) attach 1
Attaching to Remote target
warning: while parsing target memory map (at line 1): Required element <memory> is missing
0x00002fa0 in ?? ()
(gdb) monitor mass_erase
Target does not support this command.
(gdb)


BTW. In the longer term its better if we don’t do mass_erase, because the way the nRF stuff is implemented it has sort of library, which they call a SoftDevice, which sits in the bottom part of the flash, which basically does some small init and then jumps to the start of the first flash page after the SoftDevice flash memory

In the case of the “S130” Softdevice, that address seems to be 0x1C00 (the S110 Softdevice is smaller, but the code I’m currently using, is pseudo linking against the S130 sofdevice / library)

From what I’d read about the BMP, the “load” command was suppose to pre-erase the pages necessary, before flashing.

However I suspect if it doesnt know its an nRF51 that none of this stuff is happening

As a matter of interested, I looked at 0x1c00

(gdb) x/4x 0x1c000
0x1c000: 0x20004000 0x0001c789 0x0001c7c5 0x0001c7c7


RogerClark wrote:Perhaps it doesnt know its an nRF51
How do I tell GDB what process it is, perhaps the version info in the chips don’t match what BMP / GDB expect ? I know there are multiple versions of nRF51 though I’m not sure what the AAxx letters at the end of the part number actually mean.

Is there a command to read the ID?

so use an ST-Link to debug your BMP device connected to your NRF51 … a very James Taylorish looking in my review mirror moment.

Or give me a couple of days and I should have the carrier board and I can connect up my own and figure it out:

http://i66.tinypic.com/20az9yh.jpg

* you could also use 2 BMP devices to figure this out, one debugging the other.

RogerClark wrote:Is there a command to read the ID?

Rick

I actually just looked an it seems that the device ID register is at 0x1000005c

https://devzone.nordicsemi.com/question … gh-segger/

and in the BMP code this seems to be just shown as 0x5C so I guess they are the same

anyway, reading that address gives

(gdb) x/4x 0x1000005c
0x1000005c: 0xffff0084 0xa1ff477e 0xfdf8eecc 0xffffffff
(gdb)

nice, you seem to have the QFAC chip. 256/32

I updated the code for 0x0084 and pushed it to github.

Yes

It seems to have QFACAA printed on it

I think both the modules i have, are contain the same chip

I have ordered a motherboard, and it comes with another module board (well I chose to buy a motherboard that came with a module so that I’d have 3 of them)

I’ve actually found some cheaper modules, which would be more practical to use in actual real world scenarios, and which are a bit cheaper

http://www.aliexpress.com/item/10pcs-lo … 69314.html

But for dev they would need a breakout board