Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

boards/nrf52: add openocd as programmer option #9407

Merged
merged 6 commits into from Feb 26, 2019
Merged

boards/nrf52: add openocd as programmer option #9407

merged 6 commits into from Feb 26, 2019

Conversation

aabadie
Copy link
Contributor

@aabadie aabadie commented Jun 25, 2018 •
edited by maribu

Contribution description

This PR adds support for openocd as a programmer for nrf52 based board. These boards can be flashed using jlink adapter and openocd (>= 0.10.0) provides everything for this.

Unfortunately, it won't work if the application uses the softdevice blob because the build system doesn't provide a self contained binary in this case. Because of this limitation the jlink programmer is kept as the default one.
If an application requires softdevice and openocd is used then an error message is displayed. A better approach would be to merge the softdevice hex with the compiled binary before flashing it to the board. Maybe using the preflash target or by adding a new post-build target would make this possible ? Makefile experts' opinion is welcome.

Issues/PRs references

None

Testing

Update: Added testing state
Update: Added results for RuuviTag
Update: RuuviTag and Thingy:52, so no testing required

@aabadie aabadie added Area: tools Area: Supplementary tools Area: boards Area: Board ports labels Jun 25, 2018
@aabadie aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jun 25, 2018
@Citrullin
Copy link
Contributor

Thanks! Used this PR as reference for my SMT32F103 configuration with a J-Link.

@PeterKietzmann
Copy link
Member 

### Flashing Target ###
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          running
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000460 msp: 0x20000200
invalid subcommand "write_image erase /xyz/RIOT/examples/default/bin/nrf52840dk/default.elf 0"
in procedure 'flash'
/xyz/RIOT/examples/default/../../Makefile.include:447: recipe for target 'flash' failed
make: *** [flash] Error 1

@cladmi
Copy link
Contributor

cladmi commented Jul 11, 2018

A better approach would be to merge the softdevice hex with the compiled binary before flashing it to the board.

It is something I am interested in, merging a bin file into an elf. For distributing binaries there is then only one file.

But I think this should come after the ld -r pr. I managed to do it in the past by re-linking a second time, but it was not in a portable way.
This would help testing OTA on IoT-LAB as only y elf files are accepted.

Maybe using the preflash target or by adding a new post-build target would make this possible ?

Allow flashing a binary with openocd is one of the task of the OTA issue that I have in my backlog. I think it could then be done using a PREFLASH dependency.

@aabadie
Copy link
Contributor Author

aabadie commented Jul 11, 2018

@PeterKietzmann, your error is weird: 'invalid subcommand "write_image erase /xyz/RIOT/examples/default/bin/nrf52840dk/default.elf 0"'
It looks like an issue with the openocd.sh script and not related to this PR.

@aabadie
Copy link
Contributor Author

aabadie commented Aug 6, 2018

@PeterKietzmann, with the latest version of this branch I have the following output on a 'fresh' nrf52840dk board:

PROGRAMMER=openocd make BOARD=nrf52840dk -C examples/default flash term
make: Entering directory '/home/aabadie/softs/src/riot/RIOT/examples/default'
Building application "default" for "nrf52840dk" with MCU "nrf52".

"make" -C /home/aabadie/softs/src/riot/RIOT/boards/nrf52840dk
"make" -C /home/aabadie/softs/src/riot/RIOT/boards/common/nrf52xxxdk
"make" -C /home/aabadie/softs/src/riot/RIOT/core
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/nrf52
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/cortexm_common
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/cortexm_common/periph
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/nrf52/periph
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/nrf5x_common
"make" -C /home/aabadie/softs/src/riot/RIOT/cpu/nrf5x_common/periph
"make" -C /home/aabadie/softs/src/riot/RIOT/drivers
"make" -C /home/aabadie/softs/src/riot/RIOT/drivers/periph_common
"make" -C /home/aabadie/softs/src/riot/RIOT/drivers/saul
"make" -C /home/aabadie/softs/src/riot/RIOT/sys
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/auto_init
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/auto_init/saul
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/fmt
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/isrpipe
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/newlib_syscalls_default
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/phydat
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/ps
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/saul_reg
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/shell
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/shell/commands
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/tsrb
"make" -C /home/aabadie/softs/src/riot/RIOT/sys/uart_stdio
   text	   data	    bss	    dec	    hex	filename
  14116	    500	   2744	  17360	   43d0	/home/aabadie/softs/src/riot/RIOT/examples/default/bin/nrf52840dk/default.elf
/home/aabadie/softs/src/riot/RIOT/dist/tools/openocd/openocd.sh flash
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00399-g09076d10 (2018-04-12-15:43)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 44633 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          running
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
auto erase enabled
Warn : Unknown device (HWID 0x00000150)
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg/nrf52.cfg to disable it
wrote 16384 bytes from file /home/aabadie/softs/src/riot/RIOT/examples/default/bin/nrf52840dk/default.elf in 0.648434s (24.675 KiB/s)
verified 14616 bytes in 0.093123s (153.275 KiB/s)
shutdown command invoked
Warn : Flash driver of nrf52.flash does not support free_driver_priv()
Warn : Flash driver of nrf52.uicr does not support free_driver_priv()
Done flashing
/home/aabadie/softs/src/riot/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
2018-08-06 09:54:42,192 - INFO # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
help
2018-08-06 09:54:45,574 - INFO # help
2018-08-06 09:54:45,577 - INFO # Command              Description
2018-08-06 09:54:45,581 - INFO # ---------------------------------------
2018-08-06 09:54:45,584 - INFO # reboot               Reboot the node
2018-08-06 09:54:45,589 - INFO # ps                   Prints information about running threads.
2018-08-06 09:54:45,595 - INFO # saul                 interact with sensors and actuators using SAUL
>

@PeterKietzmann
Copy link
Member

@aabadie I'm still having the same issue and no Idea what to change. Maybe someone else can take over, @cladmi?

@kYc0o
Copy link
Contributor

kYc0o commented Sep 4, 2018

I might take a look soon. I believe we should make openocd the default flashing tool whenever possible.

@aabadie
Copy link
Contributor Author

aabadie commented Sep 5, 2018

I'm still having the same issue and no Idea what to change

@PeterKietzmann, can you try to change source [find target/nrf52.cfg] in source [find target/nrf51.cfg] in openocd.cfg ? I did that in IoT-LAB where the openocd 0.10 release is used. I think there's a bug with nrf52 cpu in openocd that is fixed is their master branch but not in the release.

@PeterKietzmann
Copy link
Member

@aabadie yes this works. I tend to say that the majority works on the release so we better not change this yet?

@aabadie
Copy link
Contributor Author

aabadie commented Sep 6, 2018

I tend to say that the majority works on the release so we better not change this yet?

I tend agree but I find this problem annoying. I hope openocd will release a new version soon.

Another possibility is to use nrf51.cfg instead of nrf52.cfg with a meaningful comment but this will look weird in the code. It will also have to be tested with a recent master version of openocd.

@aabadie
Copy link
Contributor Author

aabadie commented Sep 10, 2018

@PeterKietzmann, there are differences between the nrf52.cfg config file in 0.10 and my recent master version. I added the missing commands.

It still works on my setup. Can you try again with 0.10 ?

@PeterKietzmann
Copy link
Member 

### Flashing Target ###
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
XYZ/boards/common/nrf52xxxdk/dist/openocd.cfg:13: Error: invalid subcommand "create nrf52.dap -chain-position nrf52.cpu"
in procedure 'script' 
at file "embedded:startup.tcl", line 60
in procedure 'dap' called at file

@aabadie
Copy link
Contributor Author

aabadie commented Sep 10, 2018

I removed the problematic line, can you try again @PeterKietzmann ?

PeterKietzmann
PeterKietzmann reviewed Sep 10, 2018
View reviewed changes
boards/common/nrf52xxxdk/dist/openocd.cfg Outdated

$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0

flash bank $_CHIPNAME.flash nrf5 0x00000000 0 1 1 $_TARGETNAME
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just "nrf5" without a number?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it's like this on my openocd version. Let's try with an explicit target name, I just pushed this change and it still works for me.

@PeterKietzmann
Copy link
Member 

### Flashing Target ###
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Error: flash driver 'nrf5' not found

@PeterKietzmann
Copy link
Member 

### Flashing Target ###
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Error: flash driver 'nrf52' not found

@aabadie
Copy link
Contributor Author

aabadie commented Sep 10, 2018

@PeterKietzmann, I removed the 2 problematic lines and tested locally with openocd 0.10 and openocd master. It works for both. Can you test again ?

@PeterKietzmann
Copy link
Member

@aabadie sorry but now I get the initial error again :

### Flashing Target ###
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
0
Info : No device selected, using first device.
Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          running
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000460 msp: 0x20000200
invalid subcommand "write_image erase XYZ/RIOT/examples/default/bin/nrf52840dk/default.elf 0"
in procedure 'flash'

@aabadie aabadie mentioned this pull request Sep 28, 2018
Merged
@dylad
Copy link
Member

dylad commented Oct 7, 2018

Looks like the nrf52 flash driver was not in 0.10 release yet but it was added later. This may be the source of the problem.

@aabadie
Copy link
Contributor Author

aabadie commented Oct 23, 2018

I changed this PR back to its original state and added a comment in the Makefile about the need of a dev version of openocd.

@aabadie
Copy link
Contributor Author

aabadie commented Jan 30, 2019

Just retested this PR on nrf52dk, works like a charm with both JLink and OpenOCD (flash, debug, etc). examples/default cannot be flashed because it uses Nordic Softdevice blob and this is only supported with JLink.

I don't have Thingy52 and Ruuvitag for testing.

@maribu
Copy link
Member

maribu commented Jan 30, 2019

A colleague of mine has a Thingy:52 at home. He will lend it me tomorrow for testing.

@maribu
Copy link
Member

maribu commented Jan 30, 2019

@aabadie: I confirm that you addressed my remarks. So feel free to squash

@aabadie
Copy link
Contributor Author

aabadie commented Jan 30, 2019

So feel free to squash

Done

A colleague of mine has a Thingy:52 at home. He will lend it me tomorrow for testing.

Maybe you could also give a try to #10793 ?

@maribu
Copy link
Member

maribu commented Feb 1, 2019

My colleague lost his Thingy:52. I hope that it will turn up soon. Sorry for the delay :-(

maribu
maribu reviewed Feb 4, 2019
View reviewed changes
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found one wording issue in the documentation, so inline comments.

boards/nrf52840dk/doc.txt Outdated Show resolved Hide resolved
boards/nrf52dk/doc.txt Outdated Show resolved Hide resolved
@maribu
Copy link
Member

maribu commented Feb 4, 2019

I'm extremely sorry. My colleague searched everywhere and the board just did not turn up.

I think it is unlikely that if the OpenOCD config works for three of the nRF52 based boards that it will not work for the remaining two. Having also in mind that the jlink programmer remains the default option, merging this would not break any existing and working setup, even if there is an issue with the remaining two.

From my point of view: @aabadie should address the minor wording issue in the comment (please squash directly) and this could be merged. @PeterKietzmann what do you think?

@aabadie
Copy link
Contributor Author

aabadie commented Feb 4, 2019 •
edited

@maribu, thanks for having a second look. I'm realizing that something went wrong with my last forced push. The common documentation addition went out with the related commits. It is highly possible that I messed up with the git history when working from my other computer... I'll rework again this PR.

@aabadie aabadie force-pushed the pr/board/nrf52dk_openocd branch 2 times, most recently from 7fe80c3 to 7682946 Compare February 4, 2019 09:52
@maribu
Copy link
Member

maribu commented Feb 15, 2019

OK, got my hand on an nrf52dk and it works there. So only the RuuviTag and the Thingy:52 are left untested. @haukepetersen: Could you test it for them?

@MrKevinWeiss
Copy link
Contributor

I have a ruuvitag I can test.

@MrKevinWeiss
Copy link
Contributor

The results with/without openocd as programmer:

PROGRAMMER=openocd make BOARD=ruuvitag -C examples/default flash
make: Entering directory '/home/kevinweiss/WorkingDirectory/RIOT/examples/default'
Building application "default" for "ruuvitag" with MCU "nrf52".

"make" -C /home/kevinweiss/WorkingDirectory/RIOT/boards/ruuvitag
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/boards/common/nrf52xxxdk
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/core
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf52
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/cortexm_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/cortexm_common/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf52/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf5x_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf5x_common/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/lis2dh12
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/periph_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/saul
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/auto_init
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/auto_init/saul
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/div
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/fmt
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/newlib_syscalls_default
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/phydat
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/ps
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/saul_reg
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/shell
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/shell/commands
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/stdio_rtt
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/xtimer
   text	   data	    bss	    dec	    hex	filename
  16072	    552	   3196	  19820	   4d6c	/home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.elf
/home/kevinweiss/WorkingDirectory/RIOT/dist/tools/openocd/openocd.sh flash /home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.elf
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00399-g09076d1 (2018-04-12-17:12)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 42125 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          running
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000450 msp: 0x20000200
auto erase enabled
Info : nRF52832-QFAA(build code: B0) 512kB Flash
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg/nrf52.cfg to disable it
wrote 20480 bytes from file /home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.elf in 0.536813s (37.257 KiB/s)
verified 16624 bytes in 0.090411s (179.562 KiB/s)
shutdown command invoked
Warn : Flash driver of nrf52.flash does not support free_driver_priv()
Warn : Flash driver of nrf52.uicr does not support free_driver_priv()
Done flashing
make: Leaving directory '/home/kevinweiss/WorkingDirectory/RIOT/examples/default'

make BOARD=ruuvitag -C examples/default flash
make: Entering directory '/home/kevinweiss/WorkingDirectory/RIOT/examples/default'
Building application "default" for "ruuvitag" with MCU "nrf52".

"make" -C /home/kevinweiss/WorkingDirectory/RIOT/boards/ruuvitag
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/boards/common/nrf52xxxdk
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/core
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf52
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/cortexm_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/cortexm_common/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf52/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf5x_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/cpu/nrf5x_common/periph
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/lis2dh12
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/periph_common
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/drivers/saul
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/auto_init
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/auto_init/saul
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/div
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/fmt
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/newlib_syscalls_default
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/phydat
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/ps
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/saul_reg
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/shell
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/shell/commands
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/stdio_rtt
"make" -C /home/kevinweiss/WorkingDirectory/RIOT/sys/xtimer
   text	   data	    bss	    dec	    hex	filename
  16072	    552	   3196	  19820	   4d6c	/home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.elf
/home/kevinweiss/WorkingDirectory/RIOT/dist/tools/jlink/jlink.sh flash /home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.bin
### Flashing Target ###
### Flashing at address 0x0 ###
SEGGER J-Link Commander V6.32i (Compiled Jul 24 2018 15:20:49)
DLL version V6.32i, compiled Jul 24 2018 15:20:43


J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
Hardware version: V1.00
S/N: 682059755
VTref=3.300V
Target connection not established yet but required for command.
Device "NRF52" selected.


Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Cortex-M4 identified.
Halting CPU for downloading file.
Downloading file [/home/kevinweiss/WorkingDirectory/RIOT/examples/default/bin/ruuvitag/default.bin]...
Comparing flash   [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.



Script processing completed.

make: Leaving directory '/home/kevinweiss/WorkingDirectory/RIOT/examples/default'

@haukepetersen
Copy link
Contributor

Just did try to test this PR with the ruuvitag and the thingy52, but with limited success:

  • it seems, that something in the comibination of pyterm + segger_rtt is broken in master, so I can't even access the device's shell on master, though it works for RIOT 2018.10. Don't have the time to look into this...
  • I can't get anything flashed on the thingy52, not sure what I do wrong here...
  • with this PR, it seems the ruuvitag flashes fine, but since I don't have serial (segger_rtt) access, I can't confirm this...

@haukepetersen
Copy link
Contributor

One more finding: when using PROGRAMMER = openocd and running something like make flash term on boards that use segger_rtt as default serial (shell) interface, there seems to be a configuration problem. As the TERMPROG still depends on jlink, the term target complains about missing env variables:

...
Done flashing
/home/hauke/dev/riot/RIOT/dist/tools/jlink/jlink.sh term_rtt
### Starting RTT terminal ###
Error: No target device defined in JLINK_DEVICE env var
/home/hauke/dev/riot/RIOT/examples/hello-world/../../Makefile.include:540: recipe for target 'term' failed

@maribu
Copy link
Member

maribu commented Feb 23, 2019

@aabadie: I think the way to move this PR forward is to just test if the board in question is a RuuviTag or a Thingy:52 and then just fail. This way the openocd config can still be placed in a central place to avoid code duplication. As jlink will still be the default programmer, make flash will still work for the RuuviTag or the Thingy:52 unless someone explicitly asks for OpenOCD. I think getting OpenOCD working on those two will have to wait until someone having access to those boards and the time/dedication to get it running starts to work on that. I don't thing OpenOCD support for the other boards should be delayed till that point in time.

@aabadie
Copy link
Contributor Author

aabadie commented Feb 26, 2019

@maribu, ruuvitag and thingy52 cannot be used with openocd now. I also added a note to the common documentation about that.

@maribu maribu added the Reviewed: 3-testing The PR was tested according to the maintainer guidelines label Feb 26, 2019
maribu
maribu approved these changes Feb 26, 2019
View reviewed changes
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirm that flashing the RuuviTag or the Thingy:52 is now prevented by the build system. So ACK. Lets wait for Murdock and then (hopefully) merge

@maribu maribu merged commit ef70d2a into RIOT-OS:master Feb 26, 2019
@danpetry danpetry added this to the Release 2019.04 milestone Mar 12, 2019
@aabadie aabadie deleted the pr/board/nrf52dk_openocd branch July 4, 2019 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@PeterKietzmann PeterKietzmann PeterKietzmann left review comments

@maribu maribu maribu approved these changes

@cladmi cladmi Awaiting requested review from cladmi

@haukepetersen haukepetersen Awaiting requested review from haukepetersen

@dylad dylad Awaiting requested review from dylad

Assignees
No one assigned
Labels
Area: boards Area: Board ports Area: tools Area: Supplementary tools CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Reviewed: 1-fundamentals The fundamentals of the PR were reviewed according to the maintainer guidelines Reviewed: 2-code-design The code design of the PR was reviewed according to the maintainer guidelines Reviewed: 3-testing The PR was tested according to the maintainer guidelines Reviewed: 4-code-style The adherence to coding conventions by the PR were reviewed according to the maintainer guidelines Reviewed: 5-documentation The documentation details of the PR were reviewed according to the maintainer guidelines
Projects
None yet
Milestone
Release 2019.04
Development

Successfully merging this pull request may close these issues.

None yet
10 participants
@aabadie @Citrullin @PeterKietzmann @cladmi @kYc0o @dylad @maribu @MrKevinWeiss @haukepetersen @danpetry