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.

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

nrf52: Add riotboot support #11126

Merged
merged 1 commit into from
Mar 20, 2019
Merged

Conversation

bergzand
Copy link
Member

@bergzand bergzand commented Mar 7, 2019

Contribution description

This PR attempts to add riotboot support to the nrf52 class mcu's. Unfortunately currently not compatible with the nordic_softdevice_ble package.

Testing procedure

the default example (with and without bootloader) and the tests/riotboot test should both work with this PR

Issues/PRs references

Depends on

@bergzand bergzand added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: cpu Area: CPU/MCU ports labels Mar 7, 2019
@kaspar030
Copy link
Contributor

#9095 would automate some of the testing.

@kYc0o
Copy link
Contributor

kYc0o commented Mar 7, 2019

Nice one! However, it might be better to split b15625a in another PR, so we can show how easy is to add riotboot to a new board using the corexm.ld script 😄

@cladmi
Copy link
Contributor

cladmi commented Mar 7, 2019

Nice :)

I think we could also go for cortexm.ld with nordick_softdevice_ble, if I am correct, it would just need to define ROM_OFFSET ?= 0x1f000.

I will check this.

@bergzand
Copy link
Member Author

bergzand commented Mar 7, 2019

@kYc0o So 1 PR refactoring to the common cortexm.ld and one PR (this one) adding the riotboot feature?

@kYc0o
Copy link
Contributor

kYc0o commented Mar 7, 2019

Yep! Basically just the commit I pointed out in another PR. Thanks @bergzand !

@cladmi
Copy link
Contributor

cladmi commented Mar 7, 2019

If we handle ROM_OFFSET in riotboot.mk and cortexm_common/Makefile.include we could even work with nordick_softdevice_ble I think… But it is another PR :)

@cladmi
Copy link
Contributor

cladmi commented Mar 7, 2019

It should also either add some information about the hack for flashing with JLink as now it is said that HEXFILE is here to work for edbg.

Or if we can get this one in #11112 I can update jlink to use FLASHFILE directly.

@bergzand
Copy link
Member Author

bergzand commented Mar 7, 2019

@kYc0o See #11127

@bergzand
Copy link
Member Author

bergzand commented Mar 7, 2019

It should also either add some information about the hack for flashing with JLink as now it is said that HEXFILE is here to work for edbg.

I could use a bit more context here. Is this still in scope of this PR or is this a note for your follow up PR?

@cladmi
Copy link
Contributor

cladmi commented Mar 7, 2019

Sorry, I meant that in the following files there are infos about the fact that currently doing make flash or make riotboot/flash-slot0 needs hack to work.


# Flashing rule for edbg to flash combined/extended binaries

And they do not mention JLink, and work because currently also jlink.inc.mk does HEXFILE = $(BINFILE) and flash with HEXFILE.

A fix for this is to either update the mentions to also say "it is also a hack for jlink" or rush to have FLASHFILE used in Jlink. I can do the PR for this one and see.

@cladmi
Copy link
Contributor

cladmi commented Mar 7, 2019

I created the FLASHFILE pull request. I will rush to add tests for it.
Better to fix it properly if it is working than updating the work around :)

@bergzand bergzand added the State: waiting for other PR State: The PR requires another PR to be merged first label Mar 7, 2019
@cladmi cladmi added this to the Release 2019.04 milestone Mar 11, 2019
The riotboot feature is not compatible with the nordic_softdevice_ble
package at the moment
@bergzand bergzand force-pushed the pr/nrf52/riotboot branch from a937ca5 to 005710e Compare March 14, 2019 11:03
@bergzand bergzand added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: waiting for other PR State: The PR requires another PR to be merged first labels Mar 14, 2019
@bergzand
Copy link
Member Author

Rebased

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

I will re-test this :)

@bergzand
Copy link
Member Author

I will re-test this :)

Thanks!

@cladmi cladmi added the CI: run tests If set, CI server will run tests on hardware for the labeled PR label Mar 14, 2019
@kaspar030 kaspar030 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 14, 2019
@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

riotboot/flash-slot1 is not working due to the way flashing offset is handled.

JLink.sh only relies on FLASH_ADDR for the address to flash, which is described as offset to flash code into ROM memory in makefiles/vars.inc.mk, so maybe not really an address.

For flashing with an offset, I am using IMAGE_OFFSET in makefiles/boot/riotboot.mk as was done by openocd and now edbg, so I think this should now be harmonized.

I can put a hack to also take IMAGE_OFFSET into account for JLink.

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

With this patch, jlink.sh correctly gets the address for the riotboot/flash-slot-* but it looks like it is not being flashed...

diff --git a/makefiles/boot/riotboot.mk b/makefiles/boot/riotboot.mk
index 0abe2c1d7..2f7c7e1fc 100644
--- a/makefiles/boot/riotboot.mk
+++ b/makefiles/boot/riotboot.mk
@@ -128,6 +128,7 @@ riotboot/flash-extended-slot0: $(RIOTBOOT_EXTENDED_BIN) $(FLASHDEPS)

 # Flashing rule for slot 0
 riotboot/flash-slot0: export IMAGE_OFFSET=$(SLOT0_OFFSET)
+riotboot/flash-slot0: export FLASH_ADDR:=$(shell echo $$(($${FLASH_ADDR:-0}+$(SLOT0_OFFSET))))
 # Flashing rule for edbg to flash only slot 0
 riotboot/flash-slot0: HEXFILE=$(SLOT0_RIOT_BIN)
 # openocd
@@ -138,6 +139,7 @@ riotboot/flash-slot0: $(SLOT0_RIOT_BIN) $(FLASHDEPS)

 # Flashing rule for slot 1
 riotboot/flash-slot1: export IMAGE_OFFSET=$(SLOT1_OFFSET)
+riotboot/flash-slot1: export FLASH_ADDR:=$(shell echo $$(($${FLASH_ADDR:-0}+$(SLOT1_OFFSET))))
 # Flashing rule for edbg to flash only slot 1
 riotboot/flash-slot1: HEXFILE=$(SLOT1_RIOT_BIN)
 # openocd

The commands I ran:

# Flash using `flash` target
# EDITED because APP_VER is build date...
git clean -xdf tests/riotboot ; APP_VER=0 RIOT_CI_BUILD=1 BOARD=nrf52dk make -C tests/riotboot flash test 
# Correctly tests and uses slot0 with "version == 0"

# flash using `flash-slot0` target and a bigger image version
git clean -xdf tests/riotboot ; APP_VER=1 RIOT_CI_BUILD=1 BOARD=nrf52dk make -C tests/riotboot riotboot/flash-slot0 test
# ERROR still running slot0 version 0

# flash using `flash-slot1` target and an even bigger image version
git clean -xdf tests/riotboot; APP_VER=3 BOARD=nrf52dk make -C tests/riotboot clean riotboot/flash-slot1 test
# ERROR still running slot0 version 0

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

When flashing I get this error:

Downloading file [/home/harter/work/git/RIOT/tests/riotboot/bin/nrf52dk/tests_riotboot-slot1.riot.bin]...
Unspecified error -1

But flash does not exit with an error. I already noticed this but should prepare a pull request for it:
cedba94

If I flash using PROGRAMMER=openocd it correctly updates the slots.
So it looks like completely jlink related.

@bergzand
Copy link
Member Author

Ah, that explains. I've only tested this with PROGRAMMER=openocd so far. Better block this until this also works with the jlink software, as that is the default PROGRAMMER with these boards at the moment.

@danpetry
Copy link
Contributor

There were a couple of things going on here. #11200 implements handling of IMAGE_OFFSET in jlink. #11201 implements correct calculation (in hex) of the slot 1 image offset.

They're somewhat interrelated but suggest merging #11200 first, and only testing slot 0. #11201 is needed for slot 1 to work correctly, so testing of slot 1 can be done there.

@danpetry danpetry added the State: waiting for other PR State: The PR requires another PR to be merged first label Mar 18, 2019
@cladmi
Copy link
Contributor

cladmi commented Mar 19, 2019

The updated procedure from #11126 (comment) works when #11200 is applied alone. I will finish the review over there.

@cladmi cladmi added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: waiting for other PR State: The PR requires another PR to be merged first CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 20, 2019
@cladmi
Copy link
Contributor

cladmi commented Mar 20, 2019

I rebased on master now that #11200 is merged and ran the tests from #11126 (comment) which work with both PROGRAMMER=jlink and PROGRAMMER=openocd.

Copy link
Contributor

@cladmi cladmi left a comment

Choose a reason for hiding this comment

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

Reviewed and tested with the different riotboot/flash- targets with both jlink and openocd.

You can merge when CI gives the greenlight.

@bergzand
Copy link
Member Author

I rebased on master now that #11200 is merged and ran the tests from #11126 (comment) which work with both PROGRAMMER=jlink and PROGRAMMER=openocd.

Awesome, thanks for the effort you guys put into this @danpetry @cladmi!

@cladmi cladmi merged commit 2523c1b into RIOT-OS:master Mar 20, 2019
@danpetry
Copy link
Contributor

Np!

Bluetooth OTA upgrade here we come :)

@brent7984
Copy link
Contributor

Hey guys, does the cc2538dk have riotboot support. When i try to compile i receive this error, "/bin/sh: 1: Illegal number: 0xfffffffffffff800
make: *** [/home/brenton/Downloads/RIOT-pr-nrf52-riotboot/makefiles/boot/riotboot.mk:39: /home/brenton/Downloads/RIOT-pr-nrf52-riotboot/tests/riotboot/bin/cc2538dk/tests_riotboot-slot0.elf] Error 2"
Does anyone have any idea on how i can fix this issue?

@emmanuelsearch
Copy link
Member

Hi @brent7984 no the cc2538 is not supported yet by riotboot.
Since it is a Cortex-M3 there is no conceptual hurdle to support it, though.
Are you interested in a port?

@brent7984
Copy link
Contributor

Hi there, I am interested in a port, could you please point me towards what needs to be done for a port. I really want to attempt this..

@fjmolinas
Copy link
Contributor

@cladmi are you still able to flash the second slot with Jlink? I'm currently unable to do it (still able with openocd)

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/francisco/workspace/RIOT/tests/riotboot/bin/nrf52840dk/tests_riotboot-slot1.1563953199.riot.bin]...
Unspecified error -1

Script processing completed.

@cladmi
Copy link
Contributor

cladmi commented Jul 24, 2019

The command still works for me without error:

(filesize 12560)

BOARD=nrf52dk make -C tests/riotboot riotboot/flash-slot1


### Flashing Target ###
### Flashing at base address 0x0 with offset 266240 ###
...

Cortex-M4 identified.
Halting CPU for downloading file.
Downloading file [/home/harter/work/git/RIOT/tests/riotboot/bin/nrf52dk/tests_riotboot-slot1.0.riot.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (16384 bytes)
J-Link: Flash download: Total time needed: 0.290s (Prepare: 0.042s, Compare: 0.004s, Erase: 0.000s, Program: 0.234s, Verify: 0.000s, Restore: 0.008s)
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/harter/work/git/RIOT/tests/riotboot'

However it already happened to me that reset with JLink was doing nothing, and that it was working with openocd.
On my test machine I am using openocd for the board with #11470 too.

@fjmolinas
Copy link
Contributor

@cladmi do you have an nrf52840dk? It is the one I'm using and which is failing, the exact command I'm running:

make -C tests/riotboot BOARD=nrf52840dk -j3 riotboot/flash-slot1

However it already happened to me that reset with JLink was doing nothing, and that it was working with openocd.

Flashing slot0 does succeed, but not flashing slot0-extended, so it doesn't seem to be a reset problem to me.

@cladmi
Copy link
Contributor

cladmi commented Jul 24, 2019

Oh no I don't have that one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: cpu Area: CPU/MCU ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR CI: run tests If set, CI server will run tests on hardware for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants