Giter VIP home page Giter VIP logo

blackmagic's Introduction

Black Magic Probe

Firmware for the Black Magic Debug Probe.

The Black Magic Probe is a modern, in-application debugging tool for embedded microprocessors. It allows you see what is going on 'inside' an application running on an embedded microprocessor while it executes. It is able to control and examine the state of the target microprocessor using a JTAG or Serial Wire Debugging (SWD) port and on-chip debug logic provided by the microprocessor. The probe connects to a host computer using a standard USB interface. The user is able to control exactly what happens using the GNU source level debugging software, GDB. Serial Wire Output (SWO) allows the target to write tracing and logging to the host without using usb or serial port. Decoding SWO in the probe itself makes SWO viewing as simple as connecting to a serial port.

Resources

Discord

Usage

Black Magic Debug Firmware

> arm-none-eabi-gdb gpio.elf
...<GDB Copyright message>
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon s
Target voltage: 2.94V
Available Targets:
No. Att Driver
 1      STM32F40x M3/M4
(gdb) att 1
Attaching to program: /devel/en_apps/gpio/f4_discovery/gpio.elf, Remote target
0x08002298 in UsartIOCtl ()
(gdb) load
Loading section .text, size 0x5868 lma 0x8000000
Loading section .data, size 0x9e0 lma 0x8005868
Loading section .rodata, size 0x254 lma 0x8006248
Start address 0x800007c, load size 25756
Transfer rate: 31 KB/sec, 919 bytes/write.
(gdb) b main
Breakpoint 1 at 0x80000e8: file /devel/en_apps/gpio/f4_discovery/../gpio.c, line 70.
(gdb) r
Starting program: /devel/en_apps/gpio/f4_discovery/gpio.elf
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at /devel/en_apps/gpio/f4_discovery/../gpio.c:70
70      {

Black Magic Debug App

You can also build the Black Magic Debug suite as a PC program called Black Magic Debug App (BMDA).

This builds the same GDB server that is running on the Black Magic Probe. While connection to the Black Magic Probe GDB server is via serial line, connection to the Black Magic Debug App is via TCP port 2000 for the first GDB server and higher for more invocations. Use "tar(get) ext(ented) :2000" to connect.

Black Magic Debug App can talk to

  • Black Magic Probe firmware probes via the USB-serial port
  • ST-Link v2, v2.1 and v3 with recent firmware
  • CMSIS-DAP compatible probes
  • J-Link probes
  • FTDI MPSSE based probes

When connected to a single BMP supported probe, starting blackmagic w/o any arguments starts the server. When several BMP supported probes are connected, their types, position and serial number is displayed and the program exits. Add -P (position) to the next invocation to select one. For the setup from the sample session above:

In another terminal:

> blackmagic
Black Magic Debug App v1.9.2
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 8BB20A03 Black Magic Debug
 Black Magic Probe  v1.9.2
Listening on TCP: 2000

And in the GDB terminal:

(gdb) tar ext :2000
Remote debugging using :2000
(gdb) mon s
...

Black Magic Debug App also provides for Flashing, reading and verification of a binary file, by default starting at lowest flash address. The -t argument displays information about the connected target. Use -h/--help to get a list of supported options.

OS specific remarks

On *BSD and macOS, you should use /dev/cu.usbmodemXXX. There are unresolved issues with trying to use the /dev/tty.usbmodemXXX device node involving how it operates under the hood.

Getting started

Requirements

When developing this project, the following tools are required:

Additionally, depending on if you want to build/work on the firmware or Black Magic Debug App (BMDA), you also need:

Black Magic Debug Firmware

If you wish to use the older gnu-rm ARM toolchain, this is fine and works well.

If you have a toolchain from other sources and find problems, check if it's an issue with your toolchain first, and if not then open an issue, or better, submit a pull request with a fix.

Black Magic Debug App

  • GCC or Clang (Clang is not officially supported)

If you wish to enable support for 3rd party probes, and not only the official native hardware, you will also need:

  • libusb1
  • libftdi1
  • libhidapi

Building

The project is configured and built using the Meson build system, you will need to create a build directory and then configure the build depending on what you want.

The project has a couple of build options you may configure, which affect the resulting binaries. This is how you will configure the firmware for your respective probe, or enable certain features.

A non-exhaustive list of project options:

  • probe: Hardware platform where the BMD firmware will run
  • targets: Enabled debug targets
  • debug_output: Enable debug output (for debugging the BMD stack, not debug targets)
  • rtt_support: Enable RTT (Real Time Transfer) support

You may see all available project options and valid values under Project options in the output of the meson configure command.

The following commands are ran from the root of your clone of the blackmagic repository:

cd /path/to/repository/blackmagic

Building Black Magic Debug Firmware

To build the firmware you need to configure the probe hardware the firmware will run on, as well as the cross-compilation toolchain to be used.

For convenience, a cross-file for each supported hardware probe is available which provides a sane default configuration for it.

The build configuration command for the native probe may look like:

meson setup build --cross-file cross-file/native.ini

Note that even if you are using the pre-configured cross-file, you may still override it's defaults with -Doption=value in the same configuration command, or later as highlighted in Changing the build configuration.

Alternatively (for advanced users), if you wish to configure manually, for instance while writing support for a new probe, or a different toolchain, you can run:

meson setup build --cross-file cross-file/arm-none-eabi.ini -Dprobe=native -Dtargets=cortexm,stm

You now should have a build directory from where you can build the firmware, this is also where your binary files will appear.

The command meson compile will build the default targets, you may omit -C build if you run the command from within the build directory:

meson compile -C build

You should now see the resulting binaries in build, in this case:

  • blackmagic_native_firmware.bin
  • blackmagic_native_firmware.elf

These are the binary files you will use to flash to your probe.

region `rom' overflowed

It may happen, while working with non default configurations or the project's latest version from Git, that the firmware does not fit in the available space for the configured probe, this could look something like:

arm-none-eabi/bin/ld: region `rom' overflowed by 4088 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      135160 B       128 KB    103.12%
             ram:        5708 B        20 KB     27.87%
collect2: error: ld returned 1 exit status

This is not unexpected, as some hardware probe have limited space for firmware. You can get around it by disabling some features or targets support:

meson configure build -Dtargets=cortexm,stm -Drtt_support=false

Building Black Magic Debug App

The Black Magic Debug App (BMDA) is always built by default, even for firmware builds. So long as all its dependencies are found, you can find the executable under the build directory, named simply blackmagic.

If you wish to build only BMDA, you can set the hardware probe option to an empty string -Dprobe='', this is the default value:

meson setup build

You now should have a build directory from where you can build the app, this is also where your executable will appear.

The command meson compile will build the default targets, you may omit -C build if you run the command from within the build directory:

meson compile -C build

You should now see the resulting executable in build:

  • blackmagic

Changing the build configuration

You may change the configuration at any time after configuring the project, if may also change the default options while configuring for the first time.

Changing options at configure time:

meson setup build -Ddebug_output=true

Changing options after configuration:

meson configure build -Dtargets=cortexm,stm

Alternatively, you can use the equivalent but more verbose meson setup command:

meson setup build --reconfigure -Dtargets=cortexm,stm

Keep in mind that when changing the configured probe, the other default options will not change, and you may end up with a configuration that does not make sense for it. In such cases it's best to use the cross-file for the probe, not just change the probe option. For this you will need to use the meson setup command again:

meson setup build --reconfigure --cross-file=cross-file/bluepill.ini

When changing options after configuration, you may omit the argument build if you are running the command from within the build directory.

You can have multiple build directories! So if you are regularly building firmware for multiple probes we would recommend keeping an individual build directory configured for each one.

If you are working with PowerShell you may have some issue while trying to configure some options like the enabled target list -Dtargets=cortexm,stm:

PS C:\...\blackmagic\build> meson configure build -Dtargets=cortexm,stm
ParserError:
Line | 1 | meson configure build -Dtargets=cortexm,stm
     | ~ | Missing argument in parameter list.
PS D:\...\blackmagic\build>

To get around this you may wrap the options with double quotes ", in this example:

meson configure build "-Dtargets=cortexm,stm"

Working with an existing clone (used before the new meson build system was introduced)

If you are working with an existing clone of the project where you used the old make build system, or simply initialized the submodules, you may encounter issues while trying the new Meson workflow, this may look something like:

fatal: Fetched in submodule path 'deps/libopencm3', but it did not contain bed4a785eecb6c9e77e7491e196565feb96c617b. Direct fetching of that commit failed.

To get around this try running the following commands:

cd deps/libopencm3
git remote set-url origin https://github.com/blackmagic-debug/libopencm3
cd ../..
git submodule update

Alternatively, the nuclear option (BEWARE, THIS WILL ERASE ANY CHANGES THAT HAVE NOT BEEN PUSHED UPSTREAM)

git submodule deinit --force --all
meson subprojects purge --confirm

Contributing and reporting issues

Take a look at out contribution guidelines in CONTRIBUTING.

blackmagic's People

Contributors

altracer avatar amyspark avatar arcanenibble avatar bufran avatar djix123 avatar dlaw avatar dragonmux avatar esden avatar fabalthazar avatar gsmcmullin avatar jamesturton avatar jcamdr avatar koendv avatar lenvm avatar lethalbit avatar markrages avatar paulfertser avatar perigoso avatar qyriad avatar richardeoin avatar schodet avatar sidprice avatar silbe avatar stoyan-shopov avatar themadinventor avatar tlyu avatar uwebonnes avatar vesim987 avatar xobs avatar zyp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

blackmagic's Issues

New nRF51822 device code needs to be added

I have just come across a new nRF51822 device IDE that does not appear in nrf51.c

On a new batch of boards I was programming one device was not recognised, and I have now checked its code and markings.

The device is marked as nRF51822QFAAH1 and its device ID is showing as 0x008F

I will post to the Nordic forum to confirm this, as Nordic don't seem to maintain a good accurate list of device codes, and update this issue when I get a response from Nordic

Issues loading code to STM32L4xxx

I'm trying to load code on to an STM32L475 (the EMF TiLDA Mk3 badge). Debugging seems to work fine, but the "load" command never succeeds. It seems to happen with any .elf file I try and throw at it:

(gdb) load
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0x6fd90 lma 0x8020000
Error writing data to flash
(gdb) load
Loading section vectors, size 0x1a0 lma 0x8000000
Loading section .text, size 0x5e94 lma 0x80001a0
Loading section .rodata, size 0x1320 lma 0x8006034
Error writing data to flash

In addition, monitor erase_mass seems to leave the chip in an unusable state:

(gdb) monitor erase_mass
Erasing flash... This may take a few seconds.  
(gdb) load
Error erasing flash with vFlashErase packet

This is reproducible with every BMP I have managed to get my hands on, both with firmware version v1.6-rc0-121-g4d6f691 and git revision 45e322b (HEAD currently).

Perhaps this is related to this comment on #119?

Mass Erase on F4 fails

I'm trying to erase a cortex m4 controller but it constantly fails.

You can find a console log below. After that, the debugger needs to be resettet to further function.

[peter@localhost ~]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.8.2
Copyright (C) 2014 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-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon version
Black Magic Probe (Firmware v1.6-rc0-50-g482070c-dirty)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
(gdb) mon swdp_scan
Target voltage: ABSENT!
Available Targets:
No. Att Driver
 1      STM32F4xx
(gdb) att 1
Attaching to Remote target
0x08000f22 in ?? ()
(gdb) mon erase_mass
Erasing flash... This may take a few seconds. -Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...

Watchdog not paused when debugging

As far as I can see both from testing and from looking at the source, the watchdog is not paused when at a breakpoint, so any applications that use watchdogs have to have the source code edited before being debugged.

It's trivial for the bmp to set the two flags for the two watchdogs to pause their counters on break.

Something that's been considered and rejected in the past or something that could be done?

Target is halted on powerup

Hi,
I guess this isn't an issue for everyone, but I'm using the BMP with a Nordic nRF51822 and when I power up, the BMP halts the nRF51

So I either have to run GDB, connect to BMP, scan for the target, attach to the target, the run the target.

Ideally, I'd like to be able to compile a version of the BMP that doesn't halt the target when its power on.

Can anyone advise how I can go about this.

Note. I've already recompiled the code as the board I'm using for the BMP has a different clock crystal to any of the other platforms, actually its a GD32 which is very similar to the STM32 and in my case it happens to have a 12Mhz instead of an 8Mhz Crystal

So I'm quite familiar with building and modifying code, but the BMP code is quite extensive and I'm not sure where to start looking

Thanks

Can't scan jtag chain containing Spartan-6 FPGA

The current jtag scan code assumes that all devices shift our IR as 0x01.
This isn't always true, as the Spartan-6 FPGA shifts out 0x11 and is detected as two devices.
The sanity check of switching all devices to bypass and counting again fails and the scan is aborted.

It should be possible to specify IR lengths for cases like this.

Eclipse can't get access to peripheral registers

Hi!
I'm using Eclipse Kepler with EmbSysRegView. The chip is STM32F2. Plugin for register examination EmbSysRegView does not show register values with BMP, but does so with J-Link. Is there anything I can do to fix that?

stuck at DFU mode

Hi,

I'm trying to flash the debugger portion of an STM32 Nucleo board with the BMP binaries.
But it's stuck in the upgrade mode even though I flashed the blackmagic.bin at 0x08002000.

I once got past the upgrade mode, but can't remember what I did to acomplish that.

what prevents the bootloader to start the BMP application?

/dev/tty.usbmodem support seems incomplete

While it works fine for the first time, after having GDB disconnect one has to replug the BMP in order to connect ever again. It seems to me that after closing the device it has to signal another DTR. I would have patched it myself, yet I wasn't sure where to hook into. Is there a better way than sending USB packets periodically?

Related:
gsmcmullin@b36242d

Flashing program over SWD

How is a new program flashed over SWD ADI interface? Is an IAP program loaded into RAM and then is it used to write flash memory?

I am wondering how to add new boards/chips to the already supported list. or is it supported out of the box through ADI interface?

Thanks!

Kinetis support may be corrupt

The current kinetis code returns flash erase and write commands with no error, so it appears to be correct. However in practice the erase and programming is just not performed due to a chain of bugs in the code.
I have fixed it and the fix is available at lyorak@c35dead
However I could try it only on Kinetis KL02, and do not want to initiate pull request for this change unless someone could try it in KL25 as well.
Changes:

  1. Fixed that the erase and program routines now check the return value of the command handler and report up the errors.
  2. Fixed that one single programming failure will not make the programming impossible until reset.
  3. Fixed the address offset of the Flash Common Command Object registers.

I believe that 1 and 2 can not cause problems on KL25 but am not 100% sure on point 3. However if you check the original code, it was using a byte swapping hack to address the last byte of the command register, due to the false assumption that writing 32 bits to this address would be correct. Instead, it is just writing 32bits consecutively from that address on, not backwards. I have changed this to point to the correct locations, and now load/file/comapre-sections gdb commands confirm that the file load actually has happened correctly on KL02. However it might still happen that the KL25 is handling the addressing diffferently and the original (addr + (x)^3 ) code works there.
Please suggest how to proceed.

Firmware upgrade successful but no cdc_acm

Dear all,

I recently got my hands on BMP. I followed the instructions found here:

  1. https://pixhawk.org/dev/jtag/black_magic_probe

I was able to get "All Operations Successful". However, when I did "dmesg", I wasn't able to see cdc_acm ttyACM0 and ttyACM1.

I suspect I am having the exact same problem as issue #43 - Black Magic Mini firmware update failed. I am having a green LED turning on once powered but nothing else.

Would be great to hear from developers on how I could get the cdc_acm ttyACM0 and ttyACM1 up again!

Many thanks,
Kenny

Can't find BMC target under gdb OSX Capitan

Hi all,

Since upgrading OSX from yosemite to capitan I'm not able to flash anymore.

I can see the device under /dev/tty.usbmodemXXXXXX but when I'm targeting it with target extended-remote /dev/tty.usbmodemXXXXXX in gdb nothing happens - not even an error.

Flashing using my Ubuntu virtual machine on OSX Capitan still works though.

I've got the Blackmagic V2 with the current 1.6 release flashed.

compiling failed on lastest commit

When I tried to use make PROBE_HOST=stlink to compile, it had these linking errors.

arm-none-eabi-gcc -o blackmagic adiv5.o adiv5_jtagdp.o adiv5_swdp.o arm7tdmi.o platform.o cortexm.o crc32.o gdb_if.o gdb_main.o gdb_packet.o hex_utils.o jtag_scan.o jtagtap.o lmi.o lpc11xx.o lpc43xx.o main.o nrf51.o command.o sam3x.o stm32f1.o stm32f4.o stm32l1.o swdptap.o target.o cdcacm.o usbuart.o  --specs=nano.specs -lopencm3_stm32f1 -Wl,--defsym,_stack=0x20005000 -Wl,-T,platforms/stm32/stlink.ld -nostartfiles -lc -lnosys -Wl,-Map=mapfile -mthumb -mcpu=cortex-m3 -Wl,-gc-sections -L../libopencm3/lib -Wl,-Ttext=0x8002000
command.o: In function `cmd_target_power':
/home/fboris/workspace/blackmagic/src/command.c:233: undefined reference to `platform_target_set_power'
/home/fboris/workspace/blackmagic/src/command.c:231: undefined reference to `platform_target_get_power'
collect2: error: ld returned 1 exit status
make[1]: *** [blackmagic] Error 1
make[1]: Leaving directory `/home/fboris/workspace/blackmagic/src'
make: *** [all] Error 2

somehow platform_target_set_power and platform_target_get_power cannot be linked to command.c. Is any problem there?
I'm using GNU Tools for ARM Embedded Processors 4.8.4 20140526 for my compiler

DFU_IFACE_STRING undeclared when building for F4Discovery

Building for the F4 Discovery host causes a compile error in the DFU part of the build:

arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/f4discovery -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -Istm32/include -mcpu=cortex-m3 -mthumb -DSTM32F4 -DF4DISCOVERY -I../libopencm3/include -Iplatforms/stm32 -c -o dfucore.o platforms/stm32/dfucore.c
platforms/stm32/dfucore.c:125:2: error: 'DFU_IFACE_STRING' undeclared here (not in a function)

I have had to modify libopencm3 to use soft float, but no changes other than that.

If I managed to use git bisect properly, then I think the failure was introduced in 14e5e8b, "Separated clean and dirty bootloader sections"

Default max number of JTAG devices is too small

At the moment JTAG_MAX_DEVS is 5, but since each STM32 IC (and I assume others) presents as a debug port and the CPU core separately, this in practice means the limit is 2 ICs on a daisychain, and JTAG_MAX_DEVS might as well be set to 4 instead of 5.

Since increasing this just uses 14 bytes of RAM or so per device, is there any reason not to increase it to say 32? I'm currently using a build with this set to 32 on a chain of 3 STM32s without issue (but had to increase it from 5 to get the scan to succeed with 3 ICs on the chain). I appreciate that daisychaining lots of microcontrollers on JTAG is uncommon but since it is supported, might as well support it with more than just two chips?

Last firmware breaks on STM32F0 devices

Running 5832d8a, I can mon swdp_scan and see my STM32F05x just fine, as is usually the case. I can't build the next commit b03cc59 (build errors) but by the following commit b644724 attempting to swdp_scan instead yields:

Target voltage: 3.3V Remote communication error. Target disconnected.: Input/output error.

This is a stock BMP mini (v1) attached to a very normal STM32F05. Everything continues to work as normal for an F1 I have lying around, but I haven't tested on any other devices.

GNU ARM 4.7.4 20130913 crash to build the firmware (requires GCC ARM 4.9.3)

Test1 KO GNU ARM Embedded 4.7.4 20130913

Tested on Windows 7 SP1 64bits (with 16GB RAM + SSD)
GNU_ARM_4_7_2013q3\bin\arm-none-eabi-gcc.exe --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.7.4 20130913 (re
lease) [ARM/embedded-4_7-branch revision 202601]

make
...
CC      main.c
cc1.exe: out of memory allocating 65536 bytes
make[1]: *** [main.o] Error 1
make: *** [all] Error 2

Test2 OK ARM Embedded 4.9.3 20141119

Tested on Windows 7 SP1 64bits (with 16GB RAM + SSD)
GNU_ARM_4_9_2014q4\bin\arm-none-eabi-gcc.exe --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.9.3 20141119 (re
lease) [ARM/embedded-4_9-branch revision 218278]

make
...
LD      blackmagic_dfu
OBJCOPY blackmagic_dfu.bin
OBJCOPY blackmagic_dfu.hex

Test3 OK ARM Embedded 4.9.3 20150529

Tested on Windows 7 SP1 64bits (with 16GB RAM + SSD)
GNU_ARM_4_9_2015q3\bin\arm-none-eabi-gcc.exe --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977]

make
...
LD      blackmagic_dfu
OBJCOPY blackmagic_dfu.bin
OBJCOPY blackmagic_dfu.hex

Test4 OK ARM Embedded 5.3.1 20160307

Tested on Windows 7 SP1 64bits (with 16GB RAM + SSD)
GNU_ARM_5_3_2016q1\bin\arm-none-eabi-gcc.exe --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 5.3.1 20160307 (re
lease) [ARM/embedded-5-branch revision 234589]

make
...
LD      blackmagic_dfu
OBJCOPY blackmagic_dfu.bin
OBJCOPY blackmagic_dfu.hex

Unable to flash STM32F302 using SWD

I'm able to scan for and attach an STM32F302 and can use erase_mass, but I'm unable to program it. It flashes successfully when using an ST-Link, and I'm able to use the BMP with the same setup to flash an F0, but this specific configuration is failing for me.

Console log:

$ arm-none-eabi-gdb
GNU gdb (7.6.50.20131218-0ubuntu1+1) 7.6.50.20131218-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=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) tar extended-remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F3
(gdb) attach 1
Attaching to Remote target
warning: while parsing target memory map (at line 1): Can't convert length="0x0000000zx" to an integer
0x0800073e in ?? ()
(gdb) load main.elf
Loading section .isr_vector, size 0x188 lma 0x8000000
Load failed
(gdb) mon erase_mass
(gdb) load main.elf
Loading section .isr_vector, size 0x188 lma 0x8000000
Load failed

Stlink v2 support?

Hi there,

what about the support of the stlink v2? Is the code from the branch stlink still valid? Are there any flash instructions?

Is there any chance that the current master state can be flashed onto the stlink?

Thanks, Julian

LPC21xx support

I would like to write support for the LPC21xx ARM7TDMI family. Maybe you could give me some hints what has to be implemented?

Ubuntu 12.10 upgrade issue

After running the stm32_mem.py script, the red led on the board starts to flash. Then when I run it again, it complains of No devices found and doesn't upgrade the firmware.

Can you please advise what I might try to get my bmpm up to date.

Cheers,
Greg

ghulands@px4:~/blackmagic/src$ sudo ../scripts/stm32_mem.py blackmagic.bin

USB Device Firmware Upgrade - Host Utility -- version 1.1
Copyright (C) 2011 Black Sphere Technologies
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

Device 005: ID 0483:5740 Black Sphere Technologies - Black Magic Probe
Failed to read device state! Assuming APP_IDLE
Run again to upgrade firmware.
ghulands@px4:~/blackmagic/src$ sudo ../scripts/stm32_mem.py blackmagic.bin

USB Device Firmware Upgrade - Host Utility -- version 1.1
Copyright (C) 2011 Black Sphere Technologies
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

No devices found!

Black Magic Mini firmware update failed

I downloaded the latest sourcecode from here on git, and tried to flash it to my BMP mini. Now, while I can get into the bootloader, the regular code does not run.

I was (and continue to be) able to compile the code, using make CROSS_COMPILE=arm-none-eabi- and install it with sudo python stm32_mem.py src/blackmagic.bin. The flash utility does report that it completed successfully. However, once I unplug the BMP and plug it back in, it does not show up in dmesg, and a device (/dev/ttyACMx) is not created.

in the #stm32 channel on freenode, I was able to obtain a known good blackmagic.bin, and I was able to flash it to my BMP. This also does not work.

When I plug it in (without the button pressed), the power led (green) lights up, but there are no messages in dmesg. If I plug it in with the button pressed, the green light is on, and the red light is flashing, and dmesg shows this:

[35915.995930] usb 1-1.5.4: new full-speed USB device number 35 using ehci-pci
[35916.090391] usb 1-1.5.4: New USB device found, idVendor=1d50, idProduct=6017
[35916.090401] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[35916.090407] usb 1-1.5.4: Product: Black Magic Probe (Upgrade)
[35916.090412] usb 1-1.5.4: Manufacturer: Black Sphere Technologies
[35916.090416] usb 1-1.5.4: SerialNumber: D5DD96FD

I then type:

$ sudo python scripts/stm32_mem.py blackmagic.bin

It says this:

USB Device Firmware Upgrade - Host Utility -- version 1.2
Copyright (C) 2011 Black Sphere Technologies
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

Device 038: ID 1d50:6017 Black Sphere Technologies - Black Magic Probe (Upgrade)
Serial D5DD96FD
Programming memory at 0x08011800
All operations complete!

At which point, the red led stops flashing, leaving only the green led. If I unplug it, and plug it back in, no message in dmesg, and only the green light comes on.

Add .editorconfig file to github please

I can see you are using Tabs in your code (I like this). Git hub stupidly shows the files on the website with a tab size of 8 which is not cool.

You can fix this by adding a .editorconfig file to the root of the project.

Feel free to use a hacked version of my file from here: https://github.com/fordp2002/ArmCopro.

This is an awesome project. Intend to contribute to it in the coming months!

I am not sure if your adapter can work with a raspberry Pi (to debug the Pi I mean).

FordP

Can't resume from programmed breakpoint.

On encountering a programmed breakpoint in the target program:
asm("bkpt");
The target correctly halts and SIGTRAP is reported back to GDB.
On attempting to resume, the program counter remains unchanged, and the breakpoint is executed again.
This makes it impossible to resume or step past a programmed breakpoint.

new discovery boards support

A few new discovery boards feature a highside switch to turn on or off the target µC. Default state is off, this way though the target reset line remains low all the time, preventing regular startup as the blackmagic_dfu assumes dfu boot mode. Since the PwrEn line is pulled up, its possible to detect its presence.
patch file:
usbdfu.txt

Upload script doesn't work with pyusb 1.0.0a3

Hi,
When installing with $ easy_install pyusb, 1.0.0a3 gets installed. When running the firmware updater, it complains because of missing functions in pyusb.

I would be great if you can update the script to support the latest, or can you let me know which version the script was coded against so I can upload the latest firmware.

Thanks,
Greg

gghmbp:src ghulands$ ../scripts/stm32_mem.py blackmagic.bin

USB Device Firmware Upgrade - Host Utility -- version 1.1
Copyright (C) 2011 Black Sphere Technologies
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

Traceback (most recent call last):
File "../scripts/stm32_mem.py", line 68, in
devs = dfu.finddevs()
File "/Users/ghulands/blackmagic/scripts/dfu.py", line 165, in finddevs
for bus in usb.busses():
File "build/bdist.macosx-10.8-intel/egg/usb/legacy.py", line 343, in busses
File "build/bdist.macosx-10.8-intel/egg/usb/legacy.py", line 339, in init
File "build/bdist.macosx-10.8-intel/egg/usb/core.py", line 856, in find
ValueError: No backend available

Current master fails to flash stm32f0discovery (stm32f051)

it works on v1.6-rc0

i will test this on a native probe, but i assume it will be the same result.

No. Att Driver
 1      STM32F0
0xfffffffe in ?? ()
(gdb) load
Loading section .isr_vector, size 0xc4 lma 0x8000000
Error writing data to flash

Unable to read nRF51 device FICR registers in gdb

It would be good if gdb could read more of the nRF51 "Factory Information Configuration Registers (FICR)"

Currently only this block of registers can be accessed (read or written)

nrf51_add_flash(t, NRF51_UICR, 0x100, 0x100);

Probably the easiest way to do this is to add this line

nrf51_add_flash(t, NRF51_FICR, 0x100, 0x100);

Below the UICR registers line

But perhaps using nrf51_add_flash is not the best way, and I should use nrf51_add_ram (even though its not RAM), to stop the flash erase code treating these as flash ???

459bae4 breaks Cortex-M0 support

I'm using the Black Magic Probe to debug a custom Kinetis KL27 board. All was well until I upgraded the firmware of my probe. I bisected the commit history and found that 8d9d6f6 works fine, but under 459bae4 "mon swdp_scan" fails with the following output:

Target voltage: 3.3V
SW-DP scan failed!

I switched between the two BMP firmware revisions several times and was careful to perform exactly the same sequence of steps each time:

  1. attach BMP by USB
  2. power up target device
  3. attach SWD cable between probe and device
  4. launch GDB and execute "target extended-remote /dev/ttyACM0" folllowed by "mon swdp_scan"

Happy to perform any additional tests that will provide useful information. Cheers, David

[RFC] Different approach in defining the target-specific data and functions

I really like how Black Magic Probe makes it so simple to hook-up GDB.

So I had a brief look at implementation and one thing I figured that basically if one will keep adding support for more and more targets, it will increment code size and require larger MCU...

So I have started thinking, what if a target functions and data where to be defined in some sort of a config file or script (may be JSON or Lua) and all the firmware need to have is the parser for that, so it wouldn't grow and the config or script files can reside on an SD card, perhaps.
If someone wanted to put the BMP on the same board as the target, they could potentially pre-parse their config (or script) and make it part of the firmware that way (in the case of Lua there exists a Lua to C compiler, for example).

It would also simplify the implementation for each new target, I suppose.

Data written to flash on LPC11C24 gets corrupted

I'm getting started with LPC11C24 here, and flash writes seems to get corrupted.

(gdb) load
Loading section .vectors, size 0x130 lma 0x0
Loading section .init_array, size 0x4 lma 0x130
Loading section .text, size 0x1c0 lma 0x134
Loading section .data, size 0x4 lma 0x2f4
Start address 0x134, load size 760
Transfer rate: 3 KB/sec, 190 bytes/write.
(gdb) compare-sections 
Section .vectors, range 0x0 -- 0x130: MIS-MATCHED!
Section .init_array, range 0x130 -- 0x134: MIS-MATCHED!
Section .text, range 0x134 -- 0x2f4: MIS-MATCHED!
Section .data, range 0x2f4 -- 0x2f8: matched.
warning: One or more sections of the remote executable does not match the loaded file
(gdb) x/wx 0x130
0x130 <_init_array_start>:  0x42900093
(gdb) detach
Detached from remote process.
(gdb) x/wx 0x130
0x130 <_init_array_start>:  0x00000139

I'd expect .vectors to mismatch, due to the signature generation, but not the other sections. Since .init_array contains an invalid address, the processor hardfaults during startup code.

EFM32HP (happy gecko) support

The Happy Gecko is not in the targets file yet. Needs a

#define EFM32_DI_PART_FAMILY_HAPPY_GECKO 77

and

case EFM32_DI_PART_FAMILY_HAPPY_GECKO: sprintf(variant_string, "EFM32 Happy Gecko); flash_page_size = 1024; break;

in efm32.c

Packet error on some printf statements using semi-hosting on gdb

On some printf type statements using semi-hosting, I get the following error:

   Ignoring packet error, continuing...
   Reply contains invalid hex digit 116

It has occurred several times with different printf statements. It happens consistently with specific statements, and only those statements. Some have arguments and some don't (like this example).

Note I am using GNU gdb (GNU Tools for ARM Embedded Processors) 7.4.1.20121207-cvs on OS X 10.7.5 with the precompiled binary from the launchpad site.

Here is the full output with set debug remote 1:

Breakpoint 4, main () at test_spi.c:219
219     debug_print("Sending more data than receiving with full auto SS and end callback...\n");
(gdb) set debug remote 1
(gdb) cont
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $s#73...Ack
Packet received: T05
Sending packet: $g#67...Ack
Packet received: 6c920000050000000500000005000000000000000100000001000000704f0020c09b0008bcbfffffbd5b5a6b59b12cc100000000584f0020ff0a0008020b000800000061584f002000a03b2200000000
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $Z1,8000a24,2#a4...Ack
Packet received: OK
Sending packet: $Z1,8000afe,2#09...Ack
Packet received: OK
Sending packet: $Z1,8000b1e,2#d5...Ack
Packet received: OK
Sending packet: $Z1,8000b40,2#a3...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $c#63...Ack
Packet received: Fwrite,00000001,200009A0,0000005E
Sending packet: $m200009a0,5e#ef...Ack
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Reply contains invalid hex digit 116
Sending packet: $F-1,58#3d...Packet instead of Ack, ignoring it
Packet instead of Ack, ignoring it
Packet instead of Ack, ignoring it
Packet instead of Ack, ignoring it
Ack
Packet received: T05
Sending packet: $g#67...Ack
Packet received: ffffffff40000000c928000040000000000000000100000001000000704f0020c09b0008bcbfffffbd5b5a6b59b12cc100000000584f00201f0b00081e0b000800000061584f002000a03b2200000000
Sending packet: $z1,8000a24,2#c4...Ack
Packet received: OK
Sending packet: $z1,8000afe,2#29...Ack
Packet received: OK
Sending packet: $z1,8000b1e,2#f5...Ack
Packet received: OK
Sending packet: $z1,8000b40,2#c3...Ack
Packet received: OK

Sending packet: $m8000b1e,4#8d...Ack
Packet received: 4ff00303
Sending packet: $m20004fc0,40#ec...Ack
Packet received: 38000000030000002d0d0008704f00200000000000000000014f00204242424242db17570001020304fa6a010001020304047101a8950008704f0020a91e0008
Breakpoint 6, main () at test_spi.c:220
220     spi.ss_ctrl = SPI_SS_SELECTDESELECT;
(gdb)

The line:

debug_print("Sending more data than receiving with full auto SS and end callback...\n");

expands out to this after the preprocessor:

do { if (1) printf("%s:%d:%s(): " "Sending more data than receiving with full auto SS and end callback...\n", "test_spi.c", 219, __func__); } while (0);

Debugging Nuttx fails

Don't know if this is the BMP's issue or Nuttx but if I use J-Link with the same bin, no errors come up.

I'm trying to debug my project with BMP but debugging session fails at the start-up with this error (these messages appear on UART):

Assertion failed at file:sched_removereadytorun.c line: 105
sp: 20004a48
stack base: 20003194
stack size: 00000400
ERROR: Stack pointer is not within the allocated stack

These are commands I send:

target extended-remote /dev/ttyACM1
mon swdp_scan
attach 1
monitor vector_catch disable hard
set mem inaccessible-by-default off
set print pretty

The Nuttx config I'm using barely differs from the stm32f4discovery's one. The only difference is another pin configuration.

The bin is successfully loaded. The only problem is debugging.

LEDs 0-1-2 stops blinking

Hi there,

I'm trying to reflash a STM32F1xx chip but I think I'm losing connection...
In gdb, when trying to attach it gets blocked. And time to time next error prints:
Ignoring packet error, continuing...

Hardware wise, only power LED is ON, the LEDs 0 to 2 are always off.
Any idea what coulb be wong?

Thanks!

BeagleBone Black support

The BeagleBone black is a low cost board based on the TI AM335x Cortex-A8.
The existing support for Cortex-A in BMP should work with this core, except that the ADIv5 JTAG-DP is not directly exposed, it's hidden behind the 'ICEPICK Module'.

To expose the JTAG-DP on the scan chain:

  • the JTAG chain must be scanned to detect the ICEPICK
  • the ICEPICK must be configured to connect the JTAG-DP in the scan chain
  • the chain must be rescanned to detect the JTAG-DP

The fact that the topology of the scan chain changes dynamically is problematic. The current scan code in BMP resets the JTAG logic, which will disconnect the JTAG-DP. Some refactoring around JTAG scanning and reset abstraction will be needed before this support can be added.

New chip support / PR maintenance and documentation

Hi,

We would like to adopt the black magic probe as default for Dronecode and we would like to avoid having to maintain our own codebase and docs. We would love to help to make this great project more visible and the default goto solution for JTAG / SWD. There are a few pain points however:

  • Documentation: Updating the BMP Firmware is a regular requirement as new MCUs are coming out which are not yet supported. The hacking page is not user friendly enough yet: https://github.com/blacksphere/blackmagic/wiki/Hacking. Can we can get access to wiki edits to help creating a user-facing firmware upgrade page? Otherwise we would have to do that in our own documentation.
  • Chip support pull requests: Is there a chance to get those reviewed and merged faster? They tend to sit for several months.

@pavel-kirienko @bendyer @tridge FYI.

STM32 F103 C8T6 undefined stack pointer

The second revision of the STM32 F103 C8T6 placed on the STM32F411E-DISCO board seems to ignore the first word as stack pointer.
After erasing the option bytes, we got a "seg-fault" because the stack pointer was pointing to reserved memory (something like 0xFFFFFFe8).
It was manually set by gdb set $msp=0x20005000 to be valid, so normal execution was possible.
The stack pointer is now 'floating' and will never be set to an initial value at startup or reset.
This problem could be solved by manually setting the $msp in the reset handler by opencm3, but the problem itself only shows by 'freeing' discovery boards, so the issue ended up here.
We advise manual patching the reset handler inside the stlink port of blackmagic probe.

sam3x: Error erasing flash with vFlashErase packet

Debugging a SAM3X chip (on the Arduino Due) works in both JTAG and SWD mode, but attempting to load a new elf fails with:

Error erasing flash with vFlashErase packet

This happens in both JTAG and SWD.

make PROBE_HOST=stlink fails on OSX

make PROBE_HOST=stlink output:

make PROBE_HOST=stlink
make -C libopencm3 lib
GENHDR include/libopencm3/efm32/efm32g/irq.yaml
GENHDR include/libopencm3/efm32/efm32gg/irq.yaml
GENHDR include/libopencm3/efm32/efm32lg/irq.yaml
GENHDR include/libopencm3/efm32/efm32tg/irq.yaml
GENHDR include/libopencm3/lm3s/irq.yaml
GENHDR include/libopencm3/lpc13xx/irq.yaml
GENHDR include/libopencm3/lpc17xx/irq.yaml
GENHDR include/libopencm3/lpc43xx/m0/irq.yaml
GENHDR include/libopencm3/lpc43xx/m4/irq.yaml
GENHDR include/libopencm3/sam/3n/irq.yaml
GENHDR include/libopencm3/sam/3x/irq.yaml
GENHDR include/libopencm3/stm32/f1/irq.yaml
GENHDR include/libopencm3/stm32/f2/irq.yaml
GENHDR include/libopencm3/stm32/f3/irq.yaml
GENHDR include/libopencm3/stm32/f4/irq.yaml
GENHDR include/libopencm3/stm32/l1/irq.yaml
BUILD lib/stm32/f1
CP libopencm3_stm32f1.ld
CC adc.c
CC can.c
CC desig.c
CC exti.c
CC ethernet.c
CC flash.c
CC gpio.c
CC rcc.c
CC rtc.c
CC timer.c
CC crc_common_all.c
CC dac_common_all.c
CC dma_common_f13.c
CC gpio_common_all.c
CC i2c_common_all.c
CC iwdg_common_all.c
CC pwr_common_all.c
CC spi_common_all.c
CC spi_common_f124.c
CC timer_common_all.c
CC usart_common_all.c
CC usart_common_f124.c
CC usb.c
CC usb_control.c
CC usb_standard.c
../../usb/usb_standard.c: In function 'build_config_descriptor':
../../usb/usb_standard.c:50:16: warning: declaration of 'index' shadows a global declaration [-Wshadow]
CC usb_f103.c
CC usb_f107.c
CC usb_fx07_common.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_stm32f1.a
BUILD lib/stm32/f2
CP libopencm3_stm32f2.ld
CC gpio.c
CC exti.c
CC rcc.c
CC crc_common_all.c
CC dac_common_all.c
CC dma_common_f24.c
CC gpio_common_all.c
CC gpio_common_f234.c
CC i2c_common_all.c
CC iwdg_common_all.c
CC rtc_common_bcd.c
CC spi_common_all.c
CC spi_common_f124.c
CC timer_common_all.c
CC timer_common_f234.c
CC timer_common_f24.c
CC usart_common_all.c
CC usart_common_f124.c
CC flash_common_f234.c
CC flash_common_f24.c
CC hash_common_f24.c
CC crypto_common_f24.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_stm32f2.a
BUILD lib/stm32/f3
CP libopencm3_stm32f3.ld
CC rcc.c
CC gpio.c
CC adc.c
CC exti.c
CC i2c.c
CC spi.c
CC usart.c
CC gpio_common_all.c
CC gpio_common_f234.c
CC dac_common_all.c
CC usart_common_all.c
CC crc_common_all.c
CC iwdg_common_all.c
CC spi_common_all.c
CC dma_common_f13.c
CC timer_common_all.c
CC timer_common_f234.c
CC flash_common_f234.c
CC flash.c
CC usb.c
CC usb_control.c
CC usb_standard.c
../../usb/usb_standard.c: In function 'build_config_descriptor':
../../usb/usb_standard.c:50:16: warning: declaration of 'index' shadows a global declaration [-Wshadow]
CC usb_f103.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_stm32f3.a
BUILD lib/stm32/f4
CP libopencm3_stm32f4.ld
CC adc.c
CC can.c
CC gpio.c
CC exti.c
CC pwr.c
CC rcc.c
CC rtc.c
CC crypto.c
CC crc_common_all.c
CC dac_common_all.c
CC dma_common_f24.c
CC gpio_common_all.c
CC gpio_common_f234.c
CC i2c_common_all.c
CC iwdg_common_all.c
CC pwr_common_all.c
CC rtc_common_bcd.c
CC spi_common_all.c
CC spi_common_f124.c
CC timer_common_all.c
CC timer_common_f234.c
CC timer_common_f24.c
CC usart_common_all.c
CC usart_common_f124.c
CC flash_common_f234.c
CC flash_common_f24.c
CC hash_common_f24.c
CC crypto_common_f24.c
CC usb.c
CC usb_standard.c
../../usb/usb_standard.c: In function 'build_config_descriptor':
../../usb/usb_standard.c:50:16: warning: declaration of 'index' shadows a global declaration [-Wshadow]
CC usb_control.c
CC usb_fx07_common.c
CC usb_f107.c
CC usb_f207.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_stm32f4.a
BUILD lib/stm32/l1
CP libopencm3_stm32l1.ld
CC crc.c
CC desig.c
CC exti.c
CC flash.c
CC rcc.c
CC usart.c
CC crc_common_all.c
CC dac_common_all.c
CC dma_common_f13.c
CC gpio_common_all.c
CC gpio_common_f234.c
CC i2c_common_all.c
CC iwdg_common_all.c
CC pwr_common_all.c
CC pwr.c
CC rtc_common_bcd.c
CC spi_common_all.c
CC timer_common_all.c
CC usart_common_all.c
CC usart_common_f124.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_stm32l1.a
BUILD lib/lpc13xx
CP libopencm3_lpc13xx.ld
CC gpio.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_lpc13xx.a
BUILD lib/lpc17xx
CP libopencm3_lpc17xx.ld
CC gpio.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_lpc17xx.a
BUILD lib/lpc43xx/m4
CP libopencm3_lpc43xx.ld
CC gpio.c
CC scu.c
CC i2c.c
CC ssp.c
CC uart.c
CC timer.c
CC ipc.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_lpc43xx.a
BUILD lib/lpc43xx/m0
CP libopencm3_lpc43xx_m0.ld
CC gpio.c
CC scu.c
CC i2c.c
CC ssp.c
CC uart.c
CC timer.c
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
../../cm3/sync.c:23:2: warning: #warning "Currently sync is not supported on Cortex-M0" [-Wcpp]
AR libopencm3_lpc43xx_m0.a
BUILD lib/lm3s
CP libopencm3_lm3s.ld
CC gpio.c
CC vector.c
CC assert.c
CC systick.c
CC scb.c
CC nvic.c
CC sync.c
AR libopencm3_lm3s.a
BUILD lib/lm4f
CP libopencm3_lm4f.ld
CC gpio.c
CC vector.c
CC assert.c
CC systemcontrol.c
CC rcc.c
CC uart.c
CC usb_lm4f.c
CC usb.c
CC usb_control.c
CC usb_standard.c
../usb/usb_standard.c: In function 'build_config_descriptor':
../usb/usb_standard.c:50:16: warning: declaration of 'index' shadows a global declaration [-Wshadow]
CC systick.c
CC scb.c
CC nvic.c
CC sync.c
AR libopencm3_lm4f.a
BUILD lib/efm32/efm32tg
CP libopencm3_efm32tg.ld
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_efm32tg.a
BUILD lib/efm32/efm32g
CP libopencm3_efm32g.ld
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_efm32g.a
BUILD lib/efm32/efm32lg
CP libopencm3_efm32lg.ld
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_efm32lg.a
BUILD lib/efm32/efm32gg
CP libopencm3_efm32gg.ld
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_efm32gg.a
BUILD lib/sam/3x
CP libopencm3_sam3x.ld
CC gpio.c
CC pmc.c
CC usart.c
../common/usart.c: In function 'usart_enable':
../common/usart.c:59:28: warning: unused parameter 'usart' [-Wunused-parameter]
../common/usart.c: In function 'usart_disable':
../common/usart.c:63:29: warning: unused parameter 'usart' [-Wunused-parameter]
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_sam3x.a
BUILD lib/sam/3n
CP libopencm3_sam3n.ld
CC gpio.c
CC pmc.c
CC usart.c
../common/usart.c: In function 'usart_enable':
../common/usart.c:59:28: warning: unused parameter 'usart' [-Wunused-parameter]
../common/usart.c: In function 'usart_disable':
../common/usart.c:63:29: warning: unused parameter 'usart' [-Wunused-parameter]
CC vector.c
CC systick.c
CC scb.c
CC nvic.c
CC assert.c
CC sync.c
AR libopencm3_sam3n.a
make -C src
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o adiv5.o adiv5.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o adiv5_jtagdp.o adiv5_jtagdp.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o adiv5_swdp.o adiv5_swdp.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o arm7tdmi.o arm7tdmi.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o command.o command.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o cortexm.o cortexm.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o crc32.o crc32.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o gdb_if.o platforms/stm32/gdb_if.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o gdb_main.o gdb_main.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o gdb_packet.o gdb_packet.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o hex_utils.o hex_utils.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o jtag_scan.o jtag_scan.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o jtagtap.o platforms/stm32/jtagtap.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o lmi.o lmi.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o lpc11xx.o lpc11xx.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o lpc43xx.o lpc43xx.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o main.o main.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o platform.o platforms/stlink/platform.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o sam3x.o sam3x.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o stm32f1.o stm32f1.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o stm32f4.o stm32f4.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o stm32l1.o stm32l1.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o swdptap.o platforms/stm32/swdptap.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o target.o target.c
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o cdcacm.o platforms/stm32/cdcacm.c
platforms/stm32/cdcacm.c: In function 'cdcacm_init':
platforms/stm32/cdcacm.c:547:2: warning: implicit declaration of function 'setup_vbus_irq' [-Wimplicit-function-declaration]
arm-none-eabi-gcc -Wall -Wextra -Wno-pointer-sign -Wno-char-subscripts -Wno-sign-compare -O2 -std=gnu99 -g3 -DBUILDDATE="date +"%Y%m%d"" -I. -Iinclude -Iplatforms/stlink -DVERSION_SUFFIX="../scripts/setlocalversion" -MD -mcpu=cortex-m3 -mthumb -DSTM32F1 -DDISCOVERY_STLINK -I../libopencm3/include -I platforms/stm32 -c -o usbuart.o platforms/stm32/usbuart.c
arm-none-eabi-gcc -o blackmagic adiv5.o adiv5_jtagdp.o adiv5_swdp.o arm7tdmi.o command.o cortexm.o crc32.o gdb_if.o gdb_main.o gdb_packet.o hex_utils.o jtag_scan.o jtagtap.o lmi.o lpc11xx.o lpc43xx.o main.o platform.o sam3x.o stm32f1.o stm32f4.o stm32l1.o swdptap.o target.o cdcacm.o usbuart.o --specs=nano.specs -lopencm3_stm32f1 -Wl,--defsym,_stack=0x20005000 -Wl,-T,platforms/stm32/stlink.ld -nostartfiles -lc -lnosys -Wl,-Map=mapfile -mthumb -mcpu=cortex-m3 -Wl,-gc-sections -L../libopencm3/lib -Wl,-Ttext=0x8002000
arm-none-eabi-gcc: error: nano.specs: No such file or directory
make[1]: *** [blackmagic] Error 1
make: *** [all] Error 2

Add STM32F302C8 ID

Please add the ID for the STM32F302C8 processor. I was able to make this work by adding the following line to src/stm32f1.c:

case 0x439: /* STM32F302C8 */

near line 137

srst still asserted after failed scan

When connect_srst is enabled, the pin stays asserted even if the scan failed. Then, it won't toggle on the next scans. This doesn't sound like the intended behaviour.

I tried to patch it in jtag_scan and adiv5_swdp_scan but it's not so straightforward because they can exit either normally or by an exception thrown in some subcalls.

The easiest way is to handle this in the caller code (command.c) but it's pretty ugly IMHO. Another way would be to isolate most of the scan routines code and do the assert/de-assert around it.

stm32f7 write flash error

I use to flash stm32f4 in swd or jtag mode with black magic probe without problem, but cannot do the same with stm32f7 even if logs suggests that F7 support exists.

Have tried in jtag or swd mode. I am able to use all debug stuff under debugger, but sending a "load" command reports "Error writing data to flash".

Is F7 support supposed to work with master, or is it a work in progress ?

BTW, flashing my F7 board works in DFU mode using dfu_util, or via stlink v2.1 probe and texane stlink.

Alexandre

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.