Autodetect: Blackmagic probe & MCB1700 (LPC1768)[macOS/OSX]

1

I’m getting two “ports” recognized by platformIO.

it auto selects the wrong port it seems, where I’m getting this error message:

Compiling .pio/build/lpc1768/src/main.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/core_cm3.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/system_LPC17xx.o
Archiving .pio/build/lpc1768/libcb3/libLPC17xx.a
Indexing .pio/build/lpc1768/libcb3/libLPC17xx.a
Linking .pio/build/lpc1768/firmware.elf
Checking size .pio/build/lpc1768/firmware.elf
Building .pio/build/lpc1768/firmware.bin
Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [          ]   0.2% (used 124 bytes from 65536 bytes)
PROGRAM: [          ]   0.1% (used 424 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed
CURRENT: upload_protocol = blackmagic
Looking for BlackMagic port...
Auto-detected: /dev/cu.usbmodem79AC68973
Uploading .pio/build/lpc1768/firmware.bin
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
"monitor" command not supported by this target.
Don't know how to attach.  Try "help target".
You can't do that when your target is `exec'
Section .init, range 0x8000 -- 0x800c: matched.
Section .text, range 0x800c -- 0x8148: matched.
Section .fini, range 0x8148 -- 0x8154: matched.
Section .rodata, range 0x8154 -- 0x8158: matched.
Section .ARM.exidx, range 0x8158 -- 0x8160: matched.
Section .eh_frame, range 0x8160 -- 0x8164: matched.
Section .init_array, range 0x18164 -- 0x18168: matched.
Section .fini_array, range 0x18168 -- 0x1816c: matched.
Section .data, range 0x1816c -- 0x181cc: matched.
The program is not being run.

when changing to the other port I’m getting this error message, as platformIO tried to upload the .bin file? When looking at the verbose output it seems to try to upload the correct .elf file, tho.

|-- <LPC17xx>
Compiling .pio/build/lpc1768/src/main.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/core_cm3.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/system_LPC17xx.o
Archiving .pio/build/lpc1768/libcb3/libLPC17xx.a
Indexing .pio/build/lpc1768/libcb3/libLPC17xx.a
Linking .pio/build/lpc1768/firmware.elf
Checking size .pio/build/lpc1768/firmware.elf
Building .pio/build/lpc1768/firmware.bin
Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [          ]   0.2% (used 124 bytes from 65536 bytes)
PROGRAM: [          ]   0.1% (used 424 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed
CURRENT: upload_protocol = blackmagic
Looking for BlackMagic port...
Use manually specified: /dev/cu.usbmodem79AC68971
Uploading .pio/build/lpc1768/firmware.bin
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      ARM Cortex-M
warning: while parsing target memory map (at line 1): Required element <memory> is missing
0x4b07b508 in ?? ()
Loading section .init, size 0xc lma 0x8000
Load failed
Section .init, range 0x8000 -- 0x800c: MIS-MATCHED!
warning: One or more sections of the target image does not match
the loaded file

Section .text, range 0x800c -- 0x8148: MIS-MATCHED!
Section .fini, range 0x8148 -- 0x8154: MIS-MATCHED!
Section .rodata, range 0x8154 -- 0x8158: MIS-MATCHED!
Section .ARM.exidx, range 0x8158 -- 0x8160: MIS-MATCHED!
Section .eh_frame, range 0x8160 -- 0x8164: matched.
Section .init_array, range 0x18164 -- 0x18168: MIS-MATCHED!
Section .fini_array, range 0x18168 -- 0x1816c: MIS-MATCHED!
Section .data, range 0x1816c -- 0x181cc: MIS-MATCHED!
Kill the program being debugged? (y or n) [answered Y; input not from terminal]

available ports:

/dev/cu.usbmodem79AC68971
-------------------------
Hardware ID: USB VID:PID=1D50:6018 SER=79AC6897 LOCATION=20-2
Description: Black Magic Probe

/dev/cu.usbmodem79AC68973
-------------------------
Hardware ID: USB VID:PID=1D50:6018 SER=79AC6897 LOCATION=20-2
Description: Black Magic Probe

Seems to be related to this issue: LPC1768 Debugging Error

2

The second log extract looks better as a target is detected. However, it looks as if the Black Magic Probe does not properly identify the MCU and therefore has no suitable memory map for the device. Do you have a recent version of the Black Magic Probe firmware? LPC1768 support was added about 18 months ago.

3

The BMP came today in the mail, I haven’t updated the firmware yet. I will try to do so.

4

I followed this instruction: Upgrading Firmware · blackmagic-debug/blackmagic Wiki · GitHub
Once without pressing the button while plugging the BMP in and once while pressing the button. downloaded the nightly build, checked for the latest git hash and ran that dfutil command.

both upload ports now have the same log, that is kind of stuck?

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/nxplpc/lpc1768.html
PLATFORM: NXP LPC 4.4.0 > NXP mbed LPC1768
HARDWARE: LPC1768 96MHz, 64KB RAM, 512KB Flash
DEBUG: Current (cmsis-dap) On-board (cmsis-dap) External (blackmagic, jlink)
PACKAGES: toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <LPC17xx>
Compiling .pio/build/lpc1768/src/main.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/core_cm3.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/startup_LPC17xx.o
Compiling .pio/build/lpc1768/libcb3/LPC17xx/system_LPC17xx.o
Archiving .pio/build/lpc1768/libcb3/libLPC17xx.a
Indexing .pio/build/lpc1768/libcb3/libLPC17xx.a
Linking .pio/build/lpc1768/firmware.elf
Checking size .pio/build/lpc1768/firmware.elf
Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [          ]   0.2% (used 124 bytes from 65536 bytes)
PROGRAM: [          ]   0.1% (used 628 bytes from 524288 bytes)
Building .pio/build/lpc1768/firmware.bin
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed
CURRENT: upload_protocol = blackmagic
Looking for BlackMagic port...
Use manually specified: /dev/cu.usbmodem79AC68971
Uploading .pio/build/lpc1768/firmware.bin
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response

This here stays in this state for a long time…

The other port seems to take less time and the results in this error:

<lambda>(["upload"], [".pio/build/lpc1768/firmware.bin"])
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed
CURRENT: upload_protocol = blackmagic
MethodWrapper(["upload"], [".pio/build/lpc1768/firmware.bin"])
Use manually specified: /dev/cu.usbmodem79AC68973
arm-none-eabi-gdb -nx --batch -ex "target extended-remote /dev/cu.usbmodem79AC68973" -ex "monitor swdp_scan" -ex "attach 1" -ex load -ex compare-sections -ex kill /Users/john/Documents/PlatformIO/Projects/Testing_MCB1768/.pio/build/lpc1768/firmware.elf
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
"monitor" command not supported by this target.
Don't know how to attach.  Try "help target".
You can't do that when your target is `exec'
Section .init, range 0x8000 -- 0x800c: matched.
Section .text, range 0x800c -- 0x8214: matched.
Section .fini, range 0x8214 -- 0x8220: matched.
Section .rodata, range 0x8220 -- 0x8224: matched.
Section .ARM.exidx, range 0x8224 -- 0x822c: matched.
Section .eh_frame, range 0x822c -- 0x8230: matched.
Section .init_array, range 0x18230 -- 0x18234: matched.
Section .fini_array, range 0x18234 -- 0x18238: matched.
Section .data, range 0x18238 -- 0x18298: matched.
5

In the bmp discord I’m told that the bin file is been uploaded, even tho the verbose output says that the .elf file is being uploaded. But the normal output says that the .bin file is being uploaded.

6

I’ve run some tests with my Black Magic Probe and a SAMD21 board. My findings are:

  • The port ending with 1 (/dev/cu.usbmodem........1) is the GDB server.
  • The port ending with 3 (/dev/cu.usbmodem........3) is the serial port.
  • Warnings like unrecognized item “timeout” in “qSupported” response and Remote replied unexpectedly to ‘vMustReplyEmpty’: timeout occur if I specify the serial instead of the GDB port for upload.

So I doubt that both ports produce the same output. The correct port is most certainly /dev/cu.usbmodem79AC68971.

To further investigate the problem with that port try the following commands (starting in a terminal) and show the output:

$ ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gdb
(gdb) target extended-remote /dev/cu.usbmodem79AC68971
(gdb) monitor swdp_scan
(gdb) attach 1
(gdb) quit

None of the commands should take more than a fraction of a second.

2 Likes
7 
(gdb) target extended-remote /dev/cu.usbmodem79AC68971
Remote debugging using /dev/cu.usbmodem79AC68971
(gdb) monitor swdp_scan
Target voltage: 3.3V
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
^C
Ignoring packet error, continuing...
Quit
(gdb)
^Cq
^CThe target is not responding to GDB commands.
Stop debugging it? (y or n) ^CQuit
(gdb) ^CQuit
(gdb) attach 1
Attaching to Remote target
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
^C^CThe target is not responding to GDB commands.
Stop debugging it? (y or n) ^CQuit
(gdb) exit
Undefined command: "exit".  Try "help".
(gdb) q

I hope I have not incorrectly flashed the firmware update.

I have connected the small jtag adapter to the debug interface right next to the big jtag.
mcb1700_large interface.

8

It would have been my next question how you have connected the BMP to the board. I’m not familiar with the board but the connection seems to be correct. BTW: The small one is not a JTAG connector but an SWD connector. That’s why the swdp_scan command is used (and not jtag_scan).

Still, the log output shows a communication problem between the BMP and the target MCU. It looks as if there is a wiring problem – a bad connection, swapped wires, offset plug, rotated plug… I assume you are using the provided ribbon cable for the connection (about half as wide as the BMP, 10 pin connector on both ends). Do both the BMP and the MCB1700 board still have a socket that prevents plugging it in the wrong way round (or offset by a pin row)?

9

I’m using the ribbon cable of the BMP and everything’s plugged in the way it fits. There is no other way to connect it.

IMG_20190916_224226
IMG_20190916_2242264000×2250 501 KB

10

The connections looks correct.

It’s unlikely that you have damaged the BMP with the firmware update. You can easily verify it:

$ ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gdb -ne
(gdb) target extended-remote /dev/cu.usbmodem79AC68971
(gbb) monitor version

The output should be:

Black Magic Probe (Firmware 3a6947a) (Hardware Version 3)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

3a6947a is the latest commit on the master branch. I’ve just updated my BMP as well and the release seems good.

I’m a bit out of ideas. The strange thing is that in your original question you had a log output where the target was successfully detected (1 ARM Cortex-M). In the last log output that’s no longer the case. An intermittent connection problem could explain this.

There are still some options:

  1. Measure the SWD connections between the BMP and LCP1768 pins and make sure they are working. I don’t know whether you have the equipment. In case you want to go that route, the MCP1700 schematic can be helpful.

  2. Try the JTAG interface instead of the SWD interface. If I’m not mistaken, the JTAG signals are available on the same connector. So just run jtag_scan instead of swd_scan.

  3. Try to connect the Black Magic Probe to the big JTAG connector – provided you have the necessary cables. If so run jtag_scan to see if you can detect the target.

  4. Isolate the problematic piece (MCB1700, BMP, cable) by testing each one with other hardware – provided you have or can borrow other debuggers, boards and cables.

1 Like
11

The BMP version was shown correctly, so I guess the BMP is working correctly.

Is there a possibility that I need to set some jumper differently, in order for the debug interface to work, as that board comes by default with a ulink-me probe, which I could get to kind of work with the help of Maximilian Gerhardt(giant thanks btw), but failed to flash stuff on the hardware without using the Mbed framework.

Looking at the debugging interface, there seems to be one pin missing, compared to the BMP.

IMG_20190916_235308
IMG_20190916_2353083341×1192 366 KB

jtag_scan with the cortex debug cable connected, not the big jtag interface:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
Copyright (C) 2017 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-apple-darwin10 --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) target extended-remote /dev/cu.usbmodem79AC68971
Remote debugging using /dev/cu.usbmodem79AC68971
(gdb) monitor jtag_scan
Target voltage: 3.3V
Ignoring packet error, continuing...
^CIgnoring packet error, continuing...
Quit
(gdb) q

I will have to wait a few days for the jtag adapter to arrive.

12

Conversation log from the BMP discord server:

The nickname will be replaced if I get the nice man or woman’s consent.

XXXXXXXXXX heute um 00:17 Uhr

So. There are two ‘serial’ ports on a BMP. One is talking to the gdb monitor, one is talking to the serial port. If you connect to the wrong one you will get packet errors. It looks like you’re connected to the wrong one in the screenshot you’ve posted.
The missing pin is no problem, it’s a ‘key’ so you don’t insert the lead the wrong way around.
Do you get the same behaviour when you connect to the other serial port?
…although you have target voltage, which is a bit odd. Is there a means by which you can disable the onboard debug interface? That could be interfering.
…does it have an onboard debug interface?

XXXXXXXXXX heute um 00:34 Uhr

I don’t see one in the circuit diagram ( https://www.nxp.com/downloads/en/design-support/Keil_LPC1768_Eval_Board_Schematic.pdf ) but the board should support swd and jtag debug based on that wiring, even on the 1.27mm (samtec) connector. The response for being connected to the correct port looks like;

(gdb) target extended-remote /dev/ttyACM1
Remote debugging using /dev/ttyACM1
(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      STM32L1x M3/M4
(gdb) attach 1
Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x08001540 in ?? ()
(gdb)
for the wrong port;
(gdb) target extended-remote /dev/ttyACM2
Remote debugging using /dev/ttyACM2
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb) monitor swdp_scan
"monitor" command not supported by this target.
(gdb) 
(Target is different and this one doesn't show voltage, but the principle holds....just happens to be what is on my desk right now)

jxsl13 heute um 00:45 Uhr

there is a second port, where the plug doesn’t fit.

XXXXXXXXXX heute um 00:45 Uhr

There is nothing in the MCB1700 user manual that suggests any configuration is nessessary for certain debug setups, and I don’t see anything in the circuit diagrams either.
The one near the LCD? Thats for TRACE. Don’t worry about that one. The one you are connected to should work perfectly.
On one of the two ports (probably the one ending ‘1’, do you get the (gdb) prompt back almost immediately?
if so, type monitor version so we can ensure we’re communicating

jxsl13 heute um 00:49 Uhr

(gdb) target extended-remote /dev/cu.usbmodem79AC68971
Remote debugging using /dev/cu.usbmodem79AC68971
(gdb) monitor version
Black Magic Probe (Firmware 3a6947a) (Hardware Version 3)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

XXXXXXXXXX heute um 00:50 Uhr

good. So you’re on the right port.
what happens when you try monitor swdp_scan now?

jxsl13 heute um 00:51 Uhr

target voltage, a while nothing, then repeatedly:
Ignoring packet error, continuing...

XXXXXXXXXX heute um 00:52 Uhr

So…you have a hardware problem somewhere then.
try reversing the two ends of the connecting lead.

jxsl13 heute um 00:54 Uhr

Remote debugging using /dev/cu.usbmodem79AC68971
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...

ribbon cable broken Oo?

XXXXXXXXXX heute um 00:54 Uhr

possibly, but they’re pretty hardy. Does monitor jtag_scan give you the same result?

jxsl13 heute um 00:55 Uhr

don’t I need to select a remote target first, it fails selecting the remote target already.
so I kinda cannot do the monitor command?
well, I could reverse tha cable again :smile:

XXXXXXXXXX heute um 00:56 Uhr

well, if you’re not getting a prompt up then it’s not connecting to the probe…I figured you were past that bit.
target extended-remote /dev/<device> is always needed.
…but that doesn’t need the lead to even be connected

jxsl13 heute um 00:57 Uhr

Oo

XXXXXXXXXX heute um 00:58 Uhr

so…get back to a state where you’ve got that!

jxsl13 heute um 01:01 Uhr

it might have been some copy & past eerror Oo
I tried it again with the cable reversed and it works, whysoever
but the output above shows clearly that I tried to connect to the dev…1
lol

Type "apropos word" to search for commands related to "word".
(gdb) target extended-remote /dev/cu.usbmodem79AC68971
Remote debugging using /dev/cu.usbmodem79AC68971
(gdb) monitor jtag_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Nordic nRF51 M3/M4

XXXXXXXXXX heute um 01:02 Uhr

Nordic???

jxsl13 heute um 01:03 Uhr

what is going on here xD
board clearly says LPC1768 chip
arm cortex m3 etc.

XXXXXXXXXX heute um 01:04 Uhr

try monitor jtag_scan again please…

jxsl13 heute um 01:05 Uhr

(gdb) monitor jtag_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Nordic nRF51 M3/M4

XXXXXXXXXX heute um 01:05 Uhr

…and now monitor swdp_scan

jxsl13 heute um 01:05 Uhr

Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Nordic nRF51 M3/M4

XXXXXXXXXX heute um 01:06 Uhr

ok, lets try attach 1

jxsl13 heute um 01:06 Uhr

Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x1fff1ff0 in ?? ()

XXXXXXXXXX heute um 01:08 Uhr

congratuations, you’re connected…even if it’s the wrong CPU!
try start

jxsl13 heute um 01:08 Uhr

No symbol table loaded. Use the "file" command.

XXXXXXXXXX heute um 01:09 Uhr

ah, that’s to be expected.
So. I would first try burning the 1.6.1 firmware into it (there have been changes to chip detection recently, but I have no idea if they are in the nightlies). It’s possible that you’ve got a communication issue but I doubt it because that would lead to errors. Your voltages look good so I don’t think monitor tpwr enable is going to help you. I think the 1.6.1 firmware should get you on course. I need sleep. Check in tomorrow. Good luck.

jxsl13 heute um 01:12 Uhr

thanks for the help!
good night
I was told that 1.6.1 doesn’t support my microcontroller, as it might have been added later on.
imma try anyway to hopefully get a ‘simple’ blinky example runnig.

XXXXXXXXXX heute um 01:18 Uhr

I don’t know when it was added, sorry, but looking at the git history it seems to have been 25th Mar 2018.

13

So can you confirm the short story:

  • Reversing the cable fixed the connection issue
  • The Black Magic Probe software seems to have a bug and therefore mistakenly identifies the chip as a Nordic nRF MCU
14

So it seems to be a super weird behavior of the BMP.
I do not think that it is any hardware fault, but that you need to explicitly connect the probe into the board first and then connect it to the USB port of your computer.

Secondly I have gotten an older BMP firmware to flash a Blinky example(Mbed framework) but that threw a warning

Use manually specified: /dev/cu.usbmodem79AC68971
Uploading .pio/build/lpc1768/firmware.bin
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      LPC17xx
0x10000010 in ?? ()
warning: One or more sections of the target image does not match
the loaded file

And programming the LED actually seems to work, if I do not program it myself that is, as my attempt seems to crash the “firmware”.

The warning seems to be due to some checksum being added, that I was also experiencing with the ULINK-ME probe, where Maximilian Gerhard helped me with a custom script and stuff.

1 Like
15

Could very well be because the .bin has the correct checksum but this checksum is not present in the ELF file.