search

sandeepmistry / arduino-nRF5

Arduino Core for Nordic Semiconductor nRF5 based boards
Other
907 stars 279 forks source link

Sketch does not start after power cycling #252

Closed probonopd closed 6 years ago

probonopd commented 6 years ago

I am using a generic nRF51 board. After programming, the sketch starts (e.g., the blink sketch) -- but only until I cut power to the device.

The sketch does not run after power cycling. In other words, it stops running when I unplug and re-plug power.

Does the board need certain pull-ups/pull-downs to start the sketch after power-on? How could I debug this?

This is the board I am using:

Schematic: https://www.waveshare.com/w/upload/5/57/Core51822-Schematic.pdf

dlabun commented 6 years ago

Are you using a serial port in your project? This behavior typical of your code waiting for a console connection.

probonopd commented 6 years ago

It also happens with the blink sketch which does not use serial.

dlabun commented 6 years ago

This may be related to your programmer... Looking at the console verbose you provided in #245 it looks like your board is being placed into a breakpoint right at init(). Can you provide a more recent verbose from a success programming session?

probonopd commented 6 years ago

Using the ASCIITable.ino example sketch:

Sketch uses 3216 bytes (2%) of program storage space. Maximum is 151552 bytes.
/home/me/.arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/arm-none-eabi-gdb -quiet -cd /tmp/arduino_build_409859 -b 230400 -l 10 -ex set debug remote 0 -ex set target-async off -ex set remotetimeout 10 -ex set mem inaccessible-by-default off -ex set confirm off -ex set height 0 -ex target extended-remote /dev/ttyACM0 -ex monitor swdp_scan -ex attach 1 -ex file ASCIITable.ino.elf -ex load -ex tbreak main -ex run -ex echo \nProgram complete!\n -ex quit 
Remote debugging using /dev/ttyACM0
Attaching to Remote target
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF51
0x00018268 in ?? ()
Reading symbols from ASCIITable.ino.elf...done.
Loading section .text, size 0xc90 lma 0x18000
Loading section .ARM.exidx, size 0x8 lma 0x18c90
Loading section .data, size 0x74 lma 0x18c98
Start address 0x18288, load size 3340
Transfer rate: 13 KB/sec, 556 bytes/write.
Temporary breakpoint 1 at 0x1880a: file /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/main.cpp, line 29.
Starting program: /tmp/arduino_build_409859/ASCIITable.ino.elf 
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main ()
    at /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/main.cpp:29
29    init();

Program complete!

Programmer firmware used: http://www.stm32duino.com/viewtopic.php?f=37&t=2801#p36730

probonopd commented 6 years ago

it looks like your board is being placed into a breakpoint right at init()

I think this is due to -ex "tbreak main" in

https://github.com/sandeepmistry/arduino-nRF5/blob/12e77a11d864642e9413cc0b477f33fc284ef304/platform.txt#L151

dlabun commented 6 years ago

Can you try pulling that command out and see what happens? I honestly don't know how many people are using the BMP so you may simple be the first to test this code out.

mristau commented 6 years ago

if i understand it right the -ex tbreak main should issue a temporary breakpoint at main funktion, which might be good for debugging, so it maybe is just left in after testing the blackmagic code

probonopd commented 6 years ago

I could not get it to work when I experimented with removing -ex "tbreak main". Is anyone successfully using BMP?

dlabun commented 6 years ago

@micooke Any idea what is going with this? I think you're the only other person using the BMP.

micooke commented 6 years ago

As @mristau mentioned, the -ex "tbreak main" command allows gdb to attach at the start of main and debug. It does not affect normal execution. I'll have a look into this and the com port issue as well. I have never used the bmp with linux so havent come across it before. Ill also double check the syntax on Windows for com ports < 10.

@probonopd - i have never had this issue running windows 10 or 7. I have the same hardware, i use the waveshare ble400 for development so ill try and get to this in the next day or so.

micooke commented 6 years ago

@probonopd - it looks like a problem with the firmware on your bmp as I can replicate the issue with the firmware you linked to, but not with a standard BMP DFU bootloader build.

Two other things to check:

  1. flash the bootloader (selecting None will blank the flash contents for a fresh start)
  2. power your nrf51 from an external source, not the blue pill
  3. make sure you select the chip that matches your generic - i.e. xxac or xxaa

For reference I normally use a baite flashed with BMP using cuvoodoo's config - https://wiki.cuvoodoo.info/doku.php?id=jtag

The standard BMP build should work as long as you remove some targets (almost all) to fit on the blue pill flash. Otherwise try to build from an older BMP i.e. @rogerclarkmelbourne 's repo https://github.com/rogerclarkmelbourne/blackmagic

probonopd commented 6 years ago

Same result with BMP built and installed on the Blue Pill Board using Xubuntu 16.04 like this:

$ sudo add-apt-repository -y ppa:team-gcc-arm-embedded/ppa
$ sudo apt-get update -qq
$ sudo apt-get install -y build-essential libftdi-dev gcc-arm-embedded

$ git clone --recursive https://github.com/blacksphere/blackmagic.git
$ cd blackmagic

$ make -C libopencm3 lib
$ make -C src PROBE_HOST=stlink

# Set boot0 jumper to 1

$ sudo stm32flash -w src/blackmagic_dfu.bin -S 0x08000000 -v /dev/ttyUSB0 

# Set boot0 jumper to 0

$ lsusb
[16859.698049] usb 8-1: Product: Black Magic (Upgrade) for STLink/Discovery, (Firmware v1.6.1-107-ga9219c3)

$ sudo apt install dfu-util

$ sudo dfu-util -l

Found DFU: [1d50:6017] ver=0100, devnum=41, cfg=1, intf=0, alt=0, name="@Internal Flash   /0x08000000/8*001Ka,120*001Kg", serial="D5EB87A6"

$ sudo dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D src/blackmagic.bin 

$ lsusb

Bus 008 Device 042: ID 1d50:6018 OpenMoko, Inc.

When I upload using this programmer, the sketch runs on the nRF51 board until I cycle power.

probonopd commented 6 years ago

With xxaa I get:

/home/me/.arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/arm-none-eabi-gdb -quiet -cd /tmp/arduino_build_699309 -b 230400 -l 10 -ex set debug remote 0 -ex set target-async off -ex set remotetimeout 10 -ex set mem inaccessible-by-default off -ex set confirm off -ex set height 0 -ex target extended-remote /dev/ttyACM0 -ex monitor swdp_scan -ex attach 1 -ex file Blink.ino.elf -ex load -ex tbreak main -ex run -ex echo \nProgram complete!\n -ex quit 
Remote debugging using /dev/ttyACM0
Attaching to Remote target
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF51
0x0000025e in ?? ()
Reading symbols from Blink.ino.elf...done.
Loading section .text, size 0x638 lma 0x0
Loading section .ARM.exidx, size 0x8 lma 0x638
Loading section .data, size 0x6c lma 0x640
Start address 0x21c, load size 1708
Transfer rate: 12 KB/sec, 427 bytes/write.
Temporary breakpoint 1 at 0x422: file /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/main.cpp, line 29.
Starting program: /tmp/arduino_build_699309/Blink.ino.elf 
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main ()
    at /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/main.cpp:29
29    init();

Program complete!

and the sketch runs (but only until power is cycled).

With xxac I get:

/home/me/.arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/arm-none-eabi-gdb -quiet -cd /tmp/arduino_build_699309 -b 230400 -l 10 -ex set debug remote 0 -ex set target-async off -ex set remotetimeout 10 -ex set mem inaccessible-by-default off -ex set confirm off -ex set height 0 -ex target extended-remote /dev/ttyACM0 -ex monitor swdp_scan -ex attach 1 -ex file Blink.ino.elf -ex load -ex tbreak main -ex run -ex echo \nProgram complete!\n -ex quit 
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF51
Remote debugging using /dev/ttyACM0
Attaching to Remote target
0x00000286 in ?? ()
Reading symbols from Blink.ino.elf...done.
Loading section .text, size 0x638 lma 0x0
Loading section .ARM.exidx, size 0x8 lma 0x638
Loading section .data, size 0x6c lma 0x640
Start address 0x21c, load size 1708
Transfer rate: 12 KB/sec, 427 bytes/write.
Temporary breakpoint 1 at 0x422: file /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/main.cpp, line 29.
Starting program: /tmp/arduino_build_699309/Blink.ino.elf 
Note: automatically using hardware breakpoints for read-only addresses.

Program received signal SIGTRAP, Trace/breakpoint trap.
HardFault_Handler ()
    at /home/me/.arduino15/packages/sandeepmistry/hardware/nRF5/0.5.0/cores/nRF5/SDK/components/toolchain/gcc/gcc_startup_nrf51.S:227
227     b       .

Program complete!

and the sketch does not run (not even once).

probonopd commented 6 years ago

@micooke

I can replicate the issue with the firmware you linked to, but not with a standard BMP DFU bootloader build

Which exact build (installed how) do you use on a Blue Pill board that results in working uploads to nRF51 that can run the sketch successfully even after power cycling the nRF51?

UweBonnes commented 6 years ago

It seems you have your BMP/bluepill running and it seems you can programm the NRF. Try "compare_section" to see if programming really succeeded. Only if compare_section shows mismatch you should mistrust the BMP.

probonopd commented 6 years ago

Thanks @UweBonnes. With compare_section, are you referring to https://github.com/arduino/OpenOCD/blob/master/src/flash/nor/core.c#L541?

UweBonnes commented 6 years ago

Argh, you run obscure scripts and not gdb direct. Open the xxac script and the gdb "compare-section". The last line before should be "load" or "load <some filename"

probonopd commented 6 years ago

Argh, you run obscure scripts and not gdb direct. Open the xxac script

You are probably referring to

https://github.com/sandeepmistry/arduino-nRF5/blob/d91502dabae7392f2c02c731c20d77ba0491fd91/platform.txt#L133-L155

So I figure what I should run is

cd /tmp/arduino_build_*
sudo /home/me/.arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/arm-none-eabi-gdb -b 230400 -l 10
set debug remote 0
set target-async off
set remotetimeout 10
set mem inaccessible-by-default off
set confirm off
set height 0
target extended-remote /dev/ttyACM0
monitor swdp_scan
attach 1
file *.elf
load
compare-sections

Will try that now.

probonopd commented 6 years ago 
$ sudo /home/me/.arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 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-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) target extended-remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF51
(gdb) attach 1
Attaching to Remote target
0x00000268 in ?? ()
(gdb) file Blink.ino.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from Blink.ino.elf...done.
(gdb) load
Loading section .text, size 0x638 lma 0x18000
Loading section .ARM.exidx, size 0x8 lma 0x18638
Loading section .data, size 0x6c lma 0x18640
Start address 0x1821c, load size 1708
Transfer rate: 12 KB/sec, 427 bytes/write.
(gdb) compare-sections
Section .text, range 0x18000 -- 0x18638: matched.
Section .ARM.exidx, range 0x18638 -- 0x18640: matched.
Section .data, range 0x18640 -- 0x186ac: matched.
probonopd commented 6 years ago

When the sketch is not running after a power cycle, then I can get it to run using

(gdb) target extended-remote /dev/ttyACM0
Already connected to a remote target.  Disconnect? (y or n) y
Remote debugging using /dev/ttyACM0
(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF51

Now the sketch is running again. Until I power cycle again.

probonopd commented 6 years ago

Reliably, monitor swdp_scan starts the sketch. What do I need to do to have the sketch started automatically without the need to run monitor swdp_scan?

UweBonnes commented 6 years ago

probonopd: Is address 0x00000268 in your programm or a bootloader? Run gdb with your programm as command line argument. Then after attach, is the current programm is in your programm, gdb will show the line. Debug what is going around that address and which it is waiting. Otherwise debug what the bootloader expects and what condition is not met so that the bootloader loops waiting. I also can decipger from this hread: Does any other BMP/bluepill combination start the sketch? Or does the sketch start with the debugger unconnected? What is the reset pin of the nRF51822? Does BMP connect to that pin?

probonopd commented 6 years ago

Thanks for your help @UweBonnes. Highly appreciated. Please bear with me as I have no gdb experience nor have I written or know the details of the bootloader. I am merely trying to run an Arduino sketch on a nRF51 module using a Blue Pill board as an inexpensive uploader.

Otherwise debug what the bootloader expects and what condition is not met so that the bootloader loops waiting.

So unfortunately this is way over my head at the moment.

Is address 0x00000268 in your programm or a bootloader?

How can I know?

Does any other BMP/bluepill combination start the sketch?

I have tried two different BMP firmware versions from different sources:

In both cases, I am using the same 2$ Blue Pill board (the only one I have around).

The nRF51 board is soldered to the Blue Pill board like this:

Blue Pill nRF51822 module
3.3 VDD
GND GND
PA5 SWCLK
PB14 SWDIO
PA2 (TX) P0.00 (RX)
PA3 (RX) P0.01 (TX)

The nRF51822 module is powered through the Blue Pill. The reset lines are not connected. I do not disconnect the Blue Pill from the nRF51822 module for power cycling.

Or does the sketch start with the debugger unconnected?

Do you mean I should disconnect the lines between the nRF51822 module and the Blue Pill when power cycling? That would be a bit inconvenient since for development I have soldered everything together...

What is the reset pin of the nRF51822?

According to https://devzone.nordicsemi.com/f/nordic-q-a/1174/how-to-implement-reset-button-on-nrf51822,

SWDIO/nRESET, which is active low (ie, tied to GND when pushed).

According to https://devzone.nordicsemi.com/f/nordic-q-a/10831/reset-pin-behaviour

the pin is active low and internal pull up will be enabled if the pin is configured as reset pin (a reset needed after you have configured PSELRESET registers). (...) For the nRF51, information about the internal pull up for the reset pin can be found at section 11.1 in the nRF51 Reference Manual.

It says:

nordic

There is some code related to PSELRESET in

https://github.com/sandeepmistry/arduino-nRF5/blob/10fd652d16d7bffaae8263600d4b9646d1a7d6ba/cores/nRF5/wiring.c#L48-L61

but unlike some other boards, there is no #define RESET_PIN for the board that I am using, https://github.com/sandeepmistry/arduino-nRF5/blob/b6f690ed641a07e20ebf00911f39cae2457d9872/variants/Generic/variant.h

Does it need to be defined there, like it is for some other boards?

Does BMP connect to that pin?

No, do I need to connect them?

dlabun commented 6 years ago

You should try completely disconnecting the programmer and power cycling your board to see if the sketch will run. It's possible that when you are power cycling both boards while connected the SWD lines in an undesirable configuration that causes the nRF not to run properly.

probonopd commented 6 years ago

Thanks @dlabun. Sure enough the sketch starts when I power cycle with SWD unconnected. Is there any way around this (e.g., can the BMP disable SWD in software until it is accessed by gdb) or do I have to accept this as a fact?

dlabun commented 6 years ago

The easiest thing is to accept it. If you feel like messing with the BMP firmware you could probably modify the startup code to set the pins so that they don't interfere with the nRF startup.

You could also wire in a 2 pole switch on the SWD lines so that you can disconnect BMP without actually disconnecting any wires.

UweBonnes commented 6 years ago

probonopd: You forgot to answer if with any of the BMP incarnations you have the skecth starts up without the scan!

probonopd commented 6 years ago

You forgot to answer if with any of the BMP incarnations you have the skecth starts up without the scan!

No it does not start without the scan when SWD is connected. This is the reason why I opened this issue.

UweBonnes commented 6 years ago

Okay, now I see a problem. stlink/platform.c enables TMS without setting the OUTPUT to high. Only when the scan is started, TMS gets an idle level of high and the NRF5 starts. Can you please test following patch? iff --git a/src/platforms/stlink/platform.c b/src/platforms/stlink/platform.c index 5e2ca3b..dedf9b5 100644 --- a/src/platforms/stlink/platform.c +++ b/src/platforms/stlink/platform.c @@ -61,7 +61,12 @@ void platform_init(void) led_idle_run = GPIO9; srst_pin = SRST_PIN_V2; }

UweBonnes commented 6 years ago

diff --git a/src/platforms/stlink/platform.c b/src/platforms/stlink/platform.c index 5e2ca3b..dedf9b5 100644 --- a/src/platforms/stlink/platform.c +++ b/src/platforms/stlink/platform.c @@ -61,7 +61,12 @@ void platform_init(void) led_idle_run = GPIO9; srst_pin = SRST_PIN_V2; }

UweBonnes commented 6 years ago

Sorry, pasting the code gives crap. Next try: ``diff --git a/src/platforms/stlink/platform.c b/src/platforms/stlink/platform.c index 5e2ca3b..dedf9b5 100644 --- a/src/platforms/stlink/platform.c +++ b/src/platforms/stlink/platform.c @@ -61,7 +61,12 @@ void platform_init(void) led_idle_run = GPIO9; srst_pin = SRST_PIN_V2; }

probonopd commented 6 years ago

Thanks @UweBonnes for your help. Please use three ` characters in an otherwise blank line at the beginning and the end of the code section.

It will look like this:

Here is the code

By the way, you can edit your existing posts using the pencil icon. Thanks!

probonopd commented 6 years ago

@UweBonnes did I do it correctly here?

https://github.com/blacksphere/blackmagic/compare/master...probonopd:patch-1

UweBonnes commented 6 years ago

Yes. Find it also as https://github.com/UweBonnes/blackmagic/tree/pin-defaults

probonopd commented 6 years ago

That last link has many more changes than my patch:

https://github.com/blacksphere/blackmagic/compare/master...UweBonnes:pin-defaults

Should I use yours?

UweBonnes commented 6 years ago

There are more BMP variants than stlink/bluepill. Test either of the patches. If it solves your problem, I will send a pull request for above changes.

micooke commented 6 years ago

@probonopd - sorry I've been away. I dont use the blue pill, i normally use a stlink or baite (stlink variant) clone flashed with bmp. I use cuvoodoo's baite variant, which is linked below.

You forgot to answer if with any of the BMP incarnations you have the skecth starts up without the scan!

It might have got lost in the traffic, but the baite works without power cycling.

For reference I normally use a baite flashed with BMP using cuvoodoo's config - https://wiki.cuvoodoo.info/doku.php?id=jtag

@UweBonnes - looks like you have seen cuvoodoo's patch https://github.com/blacksphere/blackmagic/pull/274. This is what i use

UweBonnes commented 6 years ago

miccoke: The problem is the other way round. After power-up of the BMP, the sketch will not run until the scan is initialied. After that things work as expected. The branch you refer to does also not the TMS high until a scan is initiated.

UweBonnes commented 6 years ago

micooke: Gareth McMullin, the maintainer of the BMP is unhappy with the pletora of platforms that blacksphere/blackmagic#274 increases. My https://github.com/UweBonnes/blackmagic/tree/baite branch integrated the baite into the stlink platform. Test reports are welcome, as that approach has better chances for inclusion.

dlabun commented 6 years ago

I'm closing this since it's not an issue with this project, but feel free to continue the conversation.

micooke commented 6 years ago

Thanks @dlabun - yes, this is not a project issue. @UweBonnes - I can understand why BMP doesnt want to extend their support as they are trying to sell a product at the same time as providing a great OS software product :smile: .

I thought that i was using the exact version that i mentioned, but i may be missing something important. I have two baites and i remember i accidentally ripped the programming pads off of one of them so i could only update the firmware with the dfu-util. I may be using that one as my 'go to'. Previously i was using an earlier patch from cuvoodoo that was proposed when BMP was using google code, but that had a feature that it went into DFU mode if it was plugged into the target while plugging in the programmer (which was later removed).

micooke commented 6 years ago

@UweBonnes - i misread your note. You mean that you added support for the baite using the stlink v2 variant? Cool ill check it out

UweBonnes commented 6 years ago

The "hang until scan" issue is now https://github.com/blacksphere/blackmagic/issues/320. Awaiting feedback.

probonopd commented 6 years ago

UweBonnes here is what I tried:

sudo add-apt-repository -y ppa:team-gcc-arm-embedded/ppa
sudo apt-get update -qq
sudo apt-get install -y git build-essential libftdi-dev gcc-arm-embedded stm32flash dfu-util

git clone --recursive -o e8034f6 https://github.com/UweBonnes/blackmagic
cd blackmagic

make -C libopencm3 lib
make -C src PROBE_HOST=stlink

# Set boot0 jumper to 1

$ sudo stm32flash -w src/blackmagic_dfu.bin -S 0x08000000 -v /dev/ttyUSB0 

# Set boot0 jumper to 0

$ lsusb
[16859.698049] usb 8-1: Product: Black Magic (Upgrade) for STLink/Discovery, (Firmware v1.6.1-107-ga9219c3)

$ sudo apt install dfu-util

$ sudo dfu-util -l

Found DFU: [1d50:6017] ver=0100, devnum=41, cfg=1, intf=0, alt=0, name="@Internal Flash   /0x08000000/8*001Ka,120*001Kg", serial="D5EB87A6"

$ sudo dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D src/blackmagic.bin 

$ lsusb

Bus 008 Device 042: ID 1d50:6018 OpenMoko, Inc.

It works before I upload src/blackmagic.bin, the blink sketch now starts automatically after power cycling while the BMP is attached. It does NOT work after I upload src/blackmagic.bin, the blink sketch does not start after power cycling while the BMP is attached.

probonopd commented 6 years ago

Not sure if related: lately, the programming in the Arduino IDE hangs at

Starting program: /tmp/arduino_build_513162/Blink.ino.elf 
Note: automatically using hardware breakpoints for read-only addresses.

and does not exit.

UweBonnes commented 6 years ago

Unrelated tip: As you now have a recent bootloader, programm like "../scripts/stm32_mem.py blackmagic.bin" in the bmp src directory. Requires python.

Can you test with a Voltmeter or scope, if SWDIO is high while "It does NOT work after I upload src/blackmagic.bin, the blink sketch does not start after power cycling while the BMP is attached."

probonopd commented 6 years ago

B14 = SWDIO is low (at least in the "steady state"- I didn't measure what happens immediately when I power the device on. Let me know if I should do this)

micooke commented 6 years ago

@probonopd - could you try loading tsaitgaist.bin via dfu-util from here: https://gist.github.com/micooke/e9a4cf831316ace10ee6506ebbab95ed

This is what i run with. I first flashed the tsaitgaist_dfu.bin, which you may or may not need to do.

UweBonnes commented 6 years ago

probonopd: You should measure after power up, before you scan the BMP. That is where the patch change the level to high. After scan, BMP still keeps TMS (SDWIO) low, I have to think about a sensible solution for that. The problem you talked about was that after power up before scan your NRF5 did not start. This is probably caused by SWDIO lowe after startup before the patch. I would appriciate if you comment on the subject on https://github.com/blacksphere/blackmagic/issues/320.

It seems serveral problems got mixed up here. That makes it difficult to follow.

UweBonnes commented 6 years ago

micooke: Testing with cloned software cloned from clone repositories makes it hard for developpers to track what is going on. Does the tsaitgaist_dfu.bin allow DFU upload?

Awaiting feedback if https://github.com/UweBonnes/blackmagic/tree/baite is fit for purpose.