Add Riotboot support for CC2538 #11665

brent7984 · 2019-06-10T07:03:44Z

Contribution description

Testing procedure

Issues/PRs references

…t1 works.

brent7984 · 2019-06-10T07:15:31Z

Note, riotboot/flash-extended-slot0 does not work as yet. And when i flash using riotboot/flash-slotX, the other slot's image address is 0xffffffff.

brent7984 · 2019-06-10T07:34:13Z

I know work still needs to be done before this can be merged in RIOT-master. To get slots 0 and 1 to work together. The flash cca section needs to be removed after flashing the bootloader onto the board.
After flashing the bootloader, if i use the Uniflash tool to flash the slots individually, then the bootloader successfully chooses the latest version, however when i use RIOTs "cc2538-bsl" to flash the slots, it does not select the latest slot!

I am still working on this project.
Any help would be appreciated!

cladmi

Could you please provide the test commands with debug output you have while testing for reference. I would ease reviewing :)

The whole problem you will have is with the cca as it currently not taken into account at all with riotboot. If you have more infos on how this work and how it should be handled, it would help.
The whole "memory at the end that should not be touched" is a bit tricky.

The way riotboot/flash-slot0-extended and combined works is by creating a binary with only the bootloader, truncated to its size, plus the header and slot firmware. So everything that was at the end of the memory would be removed. So I understand that currently they do not work.

For the cca, I am not sure how to handle it. Somehow I think we need to keep a full flash sector for it. Otherwise, when updating over the air, bytes nearby may need to be updated and so require erasing the whole sector when erasing memory. There is a ROM_RESERVED variable that was set for the arduino bootloader to describe reserved memory at the end of the rom but is currently not yet taken into account.

Could it be possible to assume it is always there on the board and RIOT should never touch it ? Or have a flash-cca-sector target to setup the board.
However then, the flasher will need to never erase the memory.

cladmi · 2019-06-18T12:26:18Z

boards/cc2538dk/Makefile.include

@@ -23,7 +23,7 @@ RESET ?= $(RIOTBOARD)/$(BOARD)/dist/reset.sh
 export PROGRAMMER ?= cc2538-bsl

 ifeq ($(PROGRAMMER),cc2538-bsl)
-  FLASHER = $(RIOTTOOLS)/cc2538-bsl/cc2538-bsl.py
+  FLASHER = $(RIOTTOOLS)/cc2538-bsl/cc2538-bsl.py -a $(IMAGE_OFFSET)+$(ROM_START_ADDR)


This would need to go in FFLAGS instead of FLASHER.
Also, I would prefer with somehow only adding it only if IMAGE_OFFSET is set. Like in

RIOT/makefiles/tools/edbg.inc.mk

Lines 14 to 15 in fc95770

# Set offset according to IMAGE_OFFSET if it's defined

EDBG_ARGS += $(if $(IMAGE_OFFSET),--offset $(IMAGE_OFFSET))

Even if cc2538-bsl.py handles if the -a is just +rom_start as it does eval.

How does it behave if you remove the -e in FFLAGS ?

I think it would be possible to assume the CCA is always there, and just work around that memory.

I disabled the -e in FFLAGS so that i could flash the images to slots 0 and 1 individually. However it doesn't select the latest firmware. I posted my test results below. I'm not sure whether the issue is the linking of the bootloader, or the checksum

cladmi · 2019-06-18T12:28:58Z

cpu/cc2538/ldscripts/cc2538sf53.ld

+_rom_offset = DEFINED( _rom_offset ) ? _rom_offset : 0x0;
+_fw_rom_length = DEFINED( _fw_rom_length ) ? _fw_rom_length : _rom_length - _rom_offset;
+
+ASSERT((_fw_rom_length <= _rom_length - _rom_offset), "Specified firmware size does not fit in ROM");


This has now been put in common with cortexm_rom_offset.ld so you can reuse it

RIOT/cpu/kinetis/ldscripts/kinetis.ld

Line 28 in fc95770

INCLUDE cortexm_rom_offset.ld

brent7984 · 2019-06-18T14:03:03Z

Test that failed using RIOT's cc2538-bsl programmer
It currently flashes to slots 0 and 1 successfully. However the bootloader does not select the newer firmware.
I performed the test as follows:

Enable flash cca in ldscript --> This ensures the firmware generated is always 512KB and it aligns the code according to how the CC2538 requires it. It contains the 44 bytes of CCMA at the end, which is required to enable the "internal CC2538 bootloader". Note, most of the 512KB is "0xFFFF" (fillers, dependent on the size of firmware).
Flash "bootloaders/riotboot/bin/cc2538dk/riotboot.bin" to board.
Disable flash CCA in ldscript, then disable the "-e, -v" in FFLAGS.
Flash firmware via "riotboot/flash-slot0"....This successfully boots in slot 0.
Flash firmware via "riotboot/flash-slot1"....The image then boots into slot 1, even if its an older image. I assume if i used "make flash" instead of "make clean all flash" it uses the older image. Note, i copied an older slot1 image into the bin folder.
Flash newer firmware via "riotboot/flash-slot0"....Slot 1 still boots!

Note, that if i repeated the above steps, using TI's Uniflash tool instead of RIOT's cc2538-bsl programmer, the bootloader selects the newer firmware correctly.

cladmi · 2019-06-18T15:45:04Z

Hmm, the shell command does not allow printing the header of the other slot.
That would help to know the state, but it looks like the other slot is completely erased anyway.

I think it would be good to know how the flasher behaves when you do not have -e.
Could you check the content of the whole memory, it looks like you can do it with cc2538-bsl.py with the -r option and -l <the_full_rom_length>.
That could help you debug what is overwritten by comparing the hexdump.

Maybe even try to set the whole memory to 0 (except the cca maybe) and flash only the header the .hdr files at the right address.
tests_riotboot-slot0.hdr and tests_riotboot-slot1.hdr

PORT=/dev/null BOARD=cc2538dk make --no-print-directory -C tests/riotboot info-debug-variable-SLOT0_OFFSET info-debug-variable-SLOT1_OFFSET 
0x1000
264192

And check the written memory through -r or another method.

I checked the flash sector erase size in case a slot may not be aligned.
From 5.3 https://www.ti.com/lit/ds/symlink/cc2538.pdf and it is 2k (0x800)so should work with the default 0x1000 bootloader size.

It may be that it is not possible to do it through flashing with the bsl.
Or that the version we use has a bug.

fjmolinas · 2019-06-18T16:12:27Z

cpu/cc2538/ldscripts/cc2538sf53.ld


 /* Memory Space Definitions: */
 MEMORY
 {
-    rom (rx)    : ORIGIN = 0x00200000, LENGTH = 512K - 44
+    rom (rx)    : ORIGIN = _rom_start_addr + _rom_offset, LENGTH = _fw_rom_length
    cca         : ORIGIN = 0x0027ffd4, LENGTH = 44


This is a problem. when saying that cca will start at 0x0027ffd4 you will have this linked for both files, so what happens is that when flashing slot0 you are completely erasing slot1, you can see this by looking at the generated binaries (on my local computer.)

-rw-rw-r-- 1 francisco francisco 505008 Jun 18 18:09 tests_riotboot.map -rwxrwxr-x 1 francisco francisco 519936 Jun 18 18:09 tests_riotboot-slot0.bin -rwxrwxr-x 1 francisco francisco 599032 Jun 18 18:09 tests_riotboot-slot0.elf -rw-rw-r-- 1 francisco francisco 256 Jun 18 18:09 tests_riotboot-slot0.hdr -rw-rw-r-- 1 francisco francisco 520192 Jun 18 18:09 tests_riotboot-slot0.riot.bin -rwxrwxr-x 1 francisco francisco 259840 Jun 18 18:09 tests_riotboot-slot1.bin -rwxrwxr-x 1 francisco francisco 599032 Jun 18 18:09 tests_riotboot-slot1.elf

Oops, I hadn't read correctly in the description that you had disabled it manually.

Small question, what do you mean exactly by disabling the cca region? Do you comment out the section and memory definition? Could you paste the modified ld script? :)

Hi, i just commented out "SECTIONS"
`

_rom_offset = DEFINED( _rom_offset ) ? _rom_offset : 0x0;
_fw_rom_length = DEFINED( _fw_rom_length ) ? _fw_rom_length : _rom_length - _rom_offset;

ASSERT((_fw_rom_length <= _rom_length - _rom_offset), "Specified firmware size does not fit in ROM");

MEMORY
{
rom (rx) : ORIGIN = _rom_start_addr + _rom_offset, LENGTH = _fw_rom_length
cca : ORIGIN = 0x0027ffd4, LENGTH = 44
ram (w!rx) : ORIGIN = _ram_start_addr, LENGTH = _ram_length
}

/* MCU Specific Section Definitions /
*/
SECTIONS
{
.flashcca :
{
KEEP((.flashcca))
} > cca
}
/*
INCLUDE cortexm_base.ld`

I think I have similar HW as you do, I have a cc2538em + smartrf06eb board. I'll try to replicate your setup (never used any of these board or TI software so it might take me some time to get back to you). What exact hardware are you using? Just to have an Idea of the differences we might have (if any)

Hi, I am using a SmartRF06 Evaluation Board, with a CC2538EM 1.2.

fjmolinas

Some problems with how the CCFA field is handled. Not sure how this should be handled.. I'm reading about it..

fjmolinas · 2019-06-18T16:23:48Z

Re-wrote my comment upon reading the test description better: an approach for the cca field is having the bootloader be flashed first covering the whole firmware image and have the cca field be located based on the available rom. It would be wrongly located for each slot but correctly for the bootloader (although wasting 88 bytes)

brent7984 · 2019-06-19T09:13:07Z

Hey guys, I used the exact binary files using RIOTs cc2538-bsl and the Uniflash tool and did a comparison.
Files used:

Riotboot.bin (512KB flashed at 0x200000)
tests_riotboot-slot0.riot.bin (14,5KB flashed at 0x201000)
tests_riotboot-slot1.riot.bin (14,5KB flashed at 0x240800)

Test procedure:

With CCA flash enabled in ldscript --> Flash riotboot.bin (512KB)
Disable CCA flash and disable '-e' and '-v' in FFLAGS--> Flash Slot0
Flash Slot1
Flash newer Slot0
Read memory from CC2538 board after each of the above steps.
Reflashed binaries via the Uniflash tool.
Compared Memory files.

Results

Riotboot always booted newer version via Uniflash tool.
Riotboot did not boot newer version via CC2538-bsl
All memory files read were identical Except, for a few bytes at location (0x1000 which was read at 0x201000 at the CC2538 board). The different bytes occurred after the "RIOT" magic number.

fjmolinas · 2019-06-19T09:22:36Z

@brent7984 I got it too work in a hacky way. I followed the same procedure as you and got the same results. I had two problems which I think explain why it was working with "cc2538-bsl.py", but once fixed it managed to make it work.

1.- Since you removed -e flag (which is needed so everything doesn't get wiped out) the flash only succeeds the first time (when the targeted bytes are still 0xFF). But on the second time it doesn't actually write to flash since the bytes need to be in an erase state to write to them.

In the cc2538-bsl.py I added this lines just after def writeMemory(self, addr, data):

        mdebug(5, "Erasing %s bytes starting at address 0x%08X"
               % (len(data), addr))
        self.cmdEraseMemory(addr, len(data))

So this solved the problem of writing to flash. But weirdly I was still booting always from the same slot.

2.- The second problem comes from the cca array.

const uint32_t cca[] = {
    /* Bootloader Backdoor Configuration: */
    0xe0ffffff | (CCA_BACKDOOR_ENABLE << 28) | (CCA_BACKDOOR_ACTIVE_LEVEL << 27) | (CCA_BACKDOOR_PORT_A_PIN << 24),
    0x00000000,                     /**< Image Valid */
    (uint32_t)&cortex_vector_base,  /**< Application Entry Point */

    /* Unlock all pages and debug: */
    0xffffffff,
    0xffffffff,
    0xffffffff,
    0xffffffff,
    0xffffffff,
    0xffffffff,
    0xffffffff,
    0xffffffff,
};

You can see the entry point to the application is also defined here, so depending when you deleted the cca region the entry point will always be the same. In my case I had flashed combined-slot0 and the entry point was slot0 and not the bootloader so it was always booting from slot0 because it was skipping the bootloader. If i flashed bootlaoder first riotboot/flash-bootloader then deleted cca and proceeded to alternatively flash each region it worked!

Ok so the cca is still hacky, but I think we are slowly progressing (assuming this also works for you :) )

Can you try these changes? Do you think these problems can apply to what you are doing? I will try to pr the cc2538-bsl.py changes upstream so it support partial erase.

fjmolinas · 2019-06-19T09:58:08Z

Trying to PR the changes in cc2538-bsl JelmerT/cc2538-bsl#87.

fjmolinas · 2019-06-19T10:02:46Z

All memory files read were identical Except, for a few bytes at location (0x1000 which was read at 0x201000 at the CC2538 board). The different bytes occurred after the "RIOT" magic number.

I think it is because of point 1 in my comments, the version is never being re-written (the rest of the firmware is always the same anyway. Can you check if that works, you could also use JelmerT/cc2538-bsl#87.

brent7984 · 2019-06-19T11:29:41Z

Thank you for the help. It works. I'm moving on to OTA update now :)
Also, I'm new to RIOT and github, so I'm not sure what to do, should I commit the changes you suggested, or should I close this pull request?

brent7984 · 2019-06-19T11:36:20Z

What else needs to be done, for riotboot support for the CC2538 to be merged with RIOT's master base?

fjmolinas · 2019-06-19T12:39:24Z

boards/cc2538dk/Makefile.include

@@ -7,7 +7,7 @@ PROGRAMMER_SERIAL ?= 06EB

 # setup serial terminal
 # the debug UART is always the second tty with the matching serial number:
-PORT_LINUX ?= $(word 2,$(shell $(RIOTTOOLS)/usb-serial/find-tty.sh '^$(PROGRAMMER_SERIAL)'))
+PORT_LINUX ?= $(word 1,$(shell $(RIOTTOOLS)/usb-serial/find-tty.sh '^$(PROGRAMMER_SERIAL)'))


Why was this changed? Shouldn't it always be the second USB?

Yes, when I changed it to 1, it always picked up the second USB. When it was 2, it didn't pick up any USB

fjmolinas · 2019-06-19T12:40:14Z

cpu/cc2538/Makefile.include

@@ -1,3 +1,7 @@
 export CPU_ARCH := cortex-m3
-
+ROM_LEN ?= 0x80000 


Are the ROM_LEN allways the same? can it change depending on the cpu version?

I'm not sure whether if I need to decrease the ROM_LEN to account for the CCA. However when I tried 0x7FFD4 (which is 512K - 44), the flashing failed

Writing 260116 bytes starting at address 0x002407EA
Target returned: 0x43, Invalid address

Ok so since it has different length we need to set ROM_LEN and RAM_LEN according to CPU_MODEL so its taking into account for all options since this is in a common cc2538 file.

I'm not sure whether if I need to decrease the ROM_LEN to account for the CCA.

I don't think so. The problem right now is that the entry point is in the CCA field so we NEED to write it every time for normal applications, but make it always be the bootloader for riotboot.

However when I tried 0x7FFD4 (which is 512K - 44), the flashing failed

How did it fail?

it didn't flash:

Writing 260116 bytes starting at address 0x002407EA
Target returned: 0x43, Invalid address

when i tried 0x7FF00, it flashed correctly

fjmolinas · 2019-06-19T13:18:00Z

Thank you for the help. It works. I'm moving on to OTA update now :)
Also, I'm new to RIOT and github, so I'm not sure what to do, should I commit the changes you suggested, or should I close this pull request?

I don't think you should close the pull-request. The work you did is really nice. But for it to get merged in RIOT there are still some work to be done.

The changes I made target an external tool. The proper approach is to get this merged upstream and then update the reference in RIOT's tools. Which is what I'm trying to do with JelmerT/cc2538-bsl#87. Hopefully this PR or a variance of this will get merged. For now you can change the py script and commit something like: tools/cc2538-bsl: bump version. We can then fix the commit to include the commit hash if it gets merged upstream. Another commit should target changing the flash command flags.

The main problem I still see is the cca field, having to remove it is not an option we can have merged. We have to figure out a proper way to integrate this. Not sure yet how. The main problem for me is the entry point... we wan't it to always be the bootloader and not the compiled application.

You should also address the changes @cladmi pointed out. Usually what we do here is add a new commit addressing the change or a "fixup" so the changes you make and why they are made are correctly documented. A guide on this Here.

I also added some comments now.

Then there is formatting stuff and coding convention styles, as well as commit style. You can find a guide here: https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions

Anyway it would be awesome if you keep working on this, its already progressing fast, with @cladmi we can keep giving you pointers and figure out the pest solution for the cca problem.

fjmolinas · 2019-06-19T18:34:52Z

@brent7984 For cca region there is an easy solution. If make is called with CFLAGS+=-DUPDATE_CCA=0 then cca[] wont be defined and therefore won't be updated. If you do this with a board that was already flashed at least once with RIOT then it will allways work. We could filter this in cc2538dk/Makefile.include

# The entry point `cortex_vector_base` is defined in the cca field.
# If the cca field is updated when flashing a slot then the entry 
# point will never be the bootloader but the respective slot. This
# ensures it never happens .
ifneq (,$(filter riotboot,$(FEATURES_REQUIRED)))
ifneq (riotboot,$(filter riotboot,$(APPLICATION)))
  CFLAGS+=-DUPDATE_CCA=0
endif
endif

fjmolinas · 2019-06-19T19:43:47Z

boards/cc2538dk/Makefile.include

@@ -24,7 +24,7 @@ export PROGRAMMER ?= cc2538-bsl

 ifeq ($(PROGRAMMER),cc2538-bsl)
  FLASHER = $(RIOTTOOLS)/cc2538-bsl/cc2538-bsl.py
-  FFLAGS  = -p "$(PORT)" -e -w -v $(FLASHFILE)
+  FFLAGS  = -p "$(PORT)" -a $(IMAGE_OFFSET)+$(ROM_START_ADDR) -w -v $(FLASHFILE)


This should still be edited according to @cladmi suggestion, I would maybe split it in something like:

FFLAGS = -p "$(PORT)" -w -v $(FLASHFILE) FFLAGS += $(if $(IMAGE_OFFSET), -a $(shell printf "0x%08x" $$(($(IMAGE_OFFSET) + $(ROM_START_ADDR)))))

[@fjmolinas] This solution is looking good. I tested riotboot/flash-extended-slot0, and riotboot/flash-combined-slot0. Both works :)
But we currently have to flash the bootloader first (riotboot/flash-bootloader), and then the firmware. How do you suggest we integrate the 2, so we only need to use 1 command (i.e. riotboot/flash-slot0)

But we currently have to flash the bootloader first (riotboot/flash-bootloader), and then the firmware. How do you suggest we integrate the 2, so we only need to use 1 command (i.e. riotboot/flash-slot0)

why? Because of the cca field?

I tested, by flashing the hello-world example, then riotboot/flashXXXX.
riotboot/flash-extended-slot0 and riotboot/flash-combined-slot0 works fine,
However, riotboot/flash-slotX fails unless if I use riotboot/flash-bootloader first.
I believe it is because of the CCA entry point as you mentioned previously.

To program the CC2538 on the smartrf06eb, I currently have to hold the select button whilst pressing the reset button, before I flash it. Is there any way for me to bypass this procedure?

However, riotboot/flash-slotX fails unless if I use riotboot/flash-bootloader first

Hmm. Maybe the filter I defined isn't correct. What I wanted to achieve was that cca never be updated for any slot and when compiling riotboot/flash-extended-slot0 and riotboot/flash-combined-slot0 it shouldn't either. Maybe look at the bin files and see it isn't defined? If not, changing it to:

# The entry point `cortex_vector_base` is defined in the cca field. # If the cca field is updated when flashing a slot then the entry # point will never be the bootloader but the respective slot. This # ensures it never happens . ifneq (,$(filter riotboot,$(FEATURES_REQUIRED))) CFLAGS+=-DUPDATE_CCA=0 endif

would work as long as you flash some RIOT application before, like hello-world. But I'm not sure of this approach. The ideal would be that when doing riotboot/flash-extended-slot0, riotboot/flash-combined-slot0 or riotboot/flash-bootloader the cca is updated and points to the bootloader, but in no other case. I'll try to figure something out. but I don't have that much time right now, soy I might take a while to respond :) (I'll be AFK most of next week too just so you now).

I would suggest you look into ways of using UPDATE_CCA flags to achieve what I'm suggesting :)

Thanks a lot for the help. I will continue to work on it :)

I prefer a second variable over adding to FFLAGS as it prevents from overwriting it from outside. I am slowly trying to remove the FFLAGS +=.

For the cca, can we not include it in the linker if there is a rom_offset instead of a compile time hack ?
The hack does not work, as the bootloader uses riotboot.
General note, checking FEATURES_REQUIRED is forbidden (there is a sanity check for it) and should be done with FEATURES_USED.

Somehow I would still like that the combined-extended firmwares work because it is what should be distributed and is required for the tests to pass. But I do not know how to handle it properly yet.

fjmolinas · 2019-06-20T08:28:22Z

boards/cc2538dk/Makefile.include

@@ -7,7 +7,7 @@ PROGRAMMER_SERIAL ?= 06EB

 # setup serial terminal
 # the debug UART is always the second tty with the matching serial number:
-PORT_LINUX ?= $(word 2,$(shell $(RIOTTOOLS)/usb-serial/find-tty.sh '^$(PROGRAMMER_SERIAL)'))
+PORT_LINUX ?= $(word 1,$(shell $(RIOTTOOLS)/usb-serial/find-tty.sh '^$(PROGRAMMER_SERIAL)'))


I tested this on my setup and it works fine. There might be a problem with how this is defined but lets not mix things. If there is a problem we should open another PR about it, and figure out why it works for me (and presumably others) but not you.

brent7984 · 2019-06-24T08:20:01Z

Hey guys, I managed to get the CC2538 to update OTA via riotboot_flashwrite

cpu/cc2538/Makefile.include

cladmi · 2019-06-25T14:19:25Z

cpu/cc2538/Makefile.include

+	ROM_START_ADDR ?= 0x00200000
+	RAM_START_ADDR ?= 0x20000000
+	LINKER_SCRIPT ?= cc2538sf53.ld
+USEMODULE += periph_common


Why is this USEMODULE needed ?

I don't think it's needed. It was in the original RIOT base which I was working with. I've noticed it's no longer in the master base, so I'll remove it now

emmanuelsearch · 2019-08-20T09:36:52Z

@brent7984 what is the status here from your point of view?
Could you test if this works with #11818 too ?

brent7984 · 2019-08-20T11:38:03Z

@brent7984 what is the status here from your point of view?
Could you test if this works with #11818 too ?

Hi @emmanuelsearch , I tested these changes with PR #11818.
OTA upgrade via riotboot_flashwrite works, provided that I changed /sys/riotboot/flashwrite.c. The if(flashpage_write_and_verify( state->flashpage, state->flashpage_buf) != FLASHPAGE_OK) " had to be changed to a loop, the first/second writes normally failed. I'm not sure why as yet, but I could not flash to particular slots using riotboot/flash-slotX. I tested this command on this PR, and it works fine.

Note, on this PR, everything works fine, however there is one issue. In order to use the riotboot/flash-slotX command, you have to flash the bootloader first. i.e. after using riotboot/flash-bootloader or riotboot/flash-combined-slot0, then you can use riotboot/flash-slotX correctly.

emmanuelsearch · 2019-08-20T12:34:03Z

@brent7984 ok thanks for the info! Actually I meant: using your added riotboot support, can you successfully update the firmware of your cc2538 via the workflow described in the README from #11818 for simplicity using the wired version (over ethos)?

cladmi · 2019-08-20T12:37:59Z

Your board would currently be broken if rebased on the current master due to #12003.
riotboot/flash-bootloader will now fail as it will remove the flash cca section.

Flashing flash-combined-slot0 should not work as also, the cca is not currently kept with the way combined is generated.

brent7984 · 2019-08-21T07:45:12Z

I'm still trying to get the SUIT update working on the SAMR21 first. Once I get that working I'll test on the CC2538 board. For some reason, I'm getting an error
"suit_coap: error getting manifest".

benpicco · 2019-11-28T17:02:49Z

The SUIT PR is merged now so it should just work™ on SAMR21.

stale · 2020-05-31T17:33:12Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

benpicco · 2020-06-01T13:57:29Z

Sorry that it took the stale bot to remind us of this - I have an openmote-b, so I can also test this now.
Want to give this a rebase?

fjmolinas · 2020-11-13T15:28:25Z

Thanks a lot for putting the initial work in for this @brent7984 I'm sorry at the time I was not more active to push this one through :/

brent7984 · 2020-11-13T17:45:42Z

Hi @fjmolinas <https://github.com/fjmolinas> Thank you for all of your assistance, you've helped me a lot. I managed to accomplish all of my required tasks on time :) Hopefully next year, I can make a bigger contribution towards RIOT With much thanks and appreciation Brenton

…

On Fri, Nov 13, 2020 at 5:28 PM Francisco ***@***.***> wrote: Thanks a lot for putting the initial work in for this @brent7984 <https://github.com/brent7984> I'm sorry at the time I was not more active to push this one through :/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGFSPKBMN2TKDQQOSGHHRWDSPVGCRANCNFSM4HWQ5WXQ> .

brent7984 added 4 commits June 7, 2019 14:13

[commit message]

829d8af

Add riotboot support for CC2538. Separately flashing to slot0 and slo…

81ea06e

…t1 works.

Merge branch 'master' of https://github.com/brent7984/RIOT

eb1f3e2

Riotboot support CC2538

ac494ab

PeterKietzmann requested a review from cladmi June 18, 2019 07:24

cladmi reviewed Jun 18, 2019

View reviewed changes

cladmi requested a review from fjmolinas June 18, 2019 12:44

fjmolinas reviewed Jun 18, 2019

View reviewed changes

fjmolinas requested changes Jun 18, 2019

View reviewed changes

fjmolinas reviewed Jun 19, 2019

View reviewed changes

brent7984 added 3 commits June 19, 2019 15:43

CC2538 Add Partial Memory Erase

3a12575

CC2538: added FEATURES_PROVIDED += riotboot

7829fa4

CC2538: Flash with offset

dfafa49

fjmolinas reviewed Jun 19, 2019

View reviewed changes

brent7984 added 2 commits June 20, 2019 09:53

CC2538: Avoid CCA Duplicate Flash

9b55021

CC2538: Set ROM and RAM lengths according to CPU model

f6b9df1

fjmolinas reviewed Jun 20, 2019

View reviewed changes

brent7984 added 6 commits June 20, 2019 10:36

CC2538: Avoid CCA Duplicate Flash (Updated)

18c6426

CC2538: Riotboot OTA support, add Write, Erase Functionality

29a9db7

CC2538: Riotboot OTA support, ROM utility functions

e16cf4c

CC2538: Riotboot OTA support, Allow Re-flashing in case of error

3218460

CC2538: Enable Riotboot flashwrite functionality

abeef7c

CC2538: Update flashpage definitions

b632cab

aabadie added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jun 24, 2019

fix typo

e61858e

cladmi reviewed Jun 25, 2019

View reviewed changes

CC2538: remove 'USEMODULE += periph_common'

a20ad6c

stale bot added the State: stale State: The issue / PR has no activity for >185 days label May 31, 2020

stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Jun 1, 2020

fjmolinas mentioned this pull request Nov 6, 2020

boards/cc2538: add riotboot feature #15392

Merged

aabadie closed this in #15392 Nov 13, 2020

	# Set offset according to IMAGE_OFFSET if it's defined
	EDBG_ARGS += $(if $(IMAGE_OFFSET),--offset $(IMAGE_OFFSET))

		@@ -1,3 +1,7 @@
		export CPU_ARCH := cortex-m3

		ROM_LEN ?= 0x80000

Add Riotboot support for CC2538 #11665

Add Riotboot support for CC2538 #11665

Conversation

brent7984 commented Jun 10, 2019

Contribution description

Testing procedure

Issues/PRs references

brent7984 commented Jun 10, 2019

brent7984 commented Jun 10, 2019

cladmi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brent7984 commented Jun 18, 2019

cladmi commented Jun 18, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brent7984 Jun 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fjmolinas left a comment

Choose a reason for hiding this comment

fjmolinas commented Jun 18, 2019 • edited Loading

brent7984 commented Jun 19, 2019

fjmolinas commented Jun 19, 2019 • edited Loading

fjmolinas commented Jun 19, 2019

fjmolinas commented Jun 19, 2019 • edited Loading

brent7984 commented Jun 19, 2019

brent7984 commented Jun 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brent7984 Jun 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fjmolinas commented Jun 19, 2019

fjmolinas commented Jun 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brent7984 commented Jun 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emmanuelsearch commented Aug 20, 2019

brent7984 commented Aug 20, 2019 • edited Loading

emmanuelsearch commented Aug 20, 2019

cladmi commented Aug 20, 2019

brent7984 commented Aug 21, 2019

benpicco commented Nov 28, 2019

stale bot commented May 31, 2020

benpicco commented Jun 1, 2020

fjmolinas commented Nov 13, 2020

brent7984 commented Nov 13, 2020 via email

brent7984 Jun 19, 2019 •

edited

Loading

fjmolinas commented Jun 18, 2019 •

edited

Loading

fjmolinas commented Jun 19, 2019 •

edited

Loading

fjmolinas commented Jun 19, 2019 •

edited

Loading

brent7984 commented Jun 19, 2019 •

edited

Loading

brent7984 Jun 19, 2019 •

edited

Loading

brent7984 commented Aug 20, 2019 •

edited

Loading