Support for SAMD21E16A

[ruffner]

I was attempting to compile the trinket_m0 variant of this bootloader for a custom board using an E16B variant and I get an error arising from line 306 in uf2.h. after changing the chipname in the board.mk file from SAMD21E18A to SAMD21E16A.

 STATIC_ASSERT(FLASH_NUM_ROWS * 4 == FLASH_NB_OF_PAGES);

UF2 compiles for the SAMD21E16A if FLASH_NUM_ROWS is set to 256 instead of 1024 on line 169 of uf2.h, but the resulting firmware image doesn't seem to be working on my E16 based board. I was wondering if anyone has experience using this chip variant with UF2, and more specifically, what would be a good fix to make UF2 compile correctly for the E16A variant without modifying uf2.h.

[ruffner]

After reading the comments on issue #96 I am able to get my computer to recognize the board once the bootloader is flashed, but am experiencing the same problem of not being able to upload to it from Arduino.

I saw that changing the stack size was discouraged, however the total RAM is only 8k is and the default stack is 8k. when compiling UF2 this causes an overflow. This being said, is it possible to run UF2 on a micro with only 8k RAM?

[dhalbert]

It was not a goal to get UF2 to run on such small processors, so we didn't try it. But certainly try lowering the stack size incrementally to see if you can get it to work, and make sure it makes sense in the context of the the .ld file.

You could also add a little code to fill the stack with a sentinel value, run the bootloader on a '18 processor, set a breakpoint before it resets to the user program, and then see the maximum stack excursion. There is some code like this in https://github.com/adafruit/circuitpython, see around these lines:

py/stackctrl.h
50:const char MP_MAX_STACK_USAGE_SENTINEL_BYTE;

py/stackctrl.c
66:const char MP_MAX_STACK_USAGE_SENTINEL_BYTE = 0xEE;
95:	*p-- = MP_MAX_STACK_USAGE_SENTINEL_BYTE;

shared-module/ustack/__init__.c
40:    while (*p++ == MP_MAX_STACK_USAGE_SENTINEL_BYTE) { }

[ruffner]

Excellent, thank you for the insight, I will keep working on it.

Separately, would you be able to explain the difference between the *.ld and *_self.ld linker scripts?

[dhalbert]

selfmain.c et al are for the update-bootloader*.uf2 builds, which are executables that run in the program space to update the bootloader. So you load one of these .uf2's on a board with an existing bootloader, and it rewrites the bootloader region with the new version. It has to unset the BOOTPROT fuses to do this, and when it's done it sets them to re-protect the region.

[ruffner]

Okay that makes sense. So since I am testing functionality by targeting the device from the Arduino IDE, only changes that are mode to 'non-self' files will affect the resulting functionality.

[dhalbert]

That is right, but if you don't fix the self files too, then you won't be able to update the bootloader conveniently in the future.

[HpLightcorner]

@ruffner did you find out how much stack is needed?
At least I have made some experience with BOSSA... Which indeed needs either customization of the Bootloader or BOSSA itself as far as I understood.

[ruffner]

@HpLightcorner I did not. It was simpler for my application to just swap chips. I did try lowering the stack size incrementally until the bootloader would compile, however user code would still not load. Dan offered some excellent advice about measuring the actual stack used but I got the other chips sooner and didn't experiment with that approach. The '17D might have enough ram to support it, but I think the '16D is just to puny,

[HpLightcorner]

@ruffner I will further investigate the necessary resources for the 17D - currently I was focusing on the SAM-BA part and actually I think changing Arduino:XYZ to Arduino:XZ and reducing Stack to 4 kB could allow to run the boot loader on the 16D as well (at least for the SAM-BA part as no additional free RAM is needed for buffering). Would be interesting if these changes work on the 16D, maybe you can give it a try? (as I have no 16D board laying around...) The upload time on the 16D increases, but that is something a 16D user could live with. For UF2, the question is if additional free RAM Is needed?

But yeah the 16D is for sure a challenge to run on...
Reducing the stack to 4kB actually worked for me, both BOSSA and UF2 are running now without any issues.

[ruffner]

I actually replaced all the 16D chips with 18 on the four boards I brought up...sorry. Glad to hear you are making progress!

[dhalbert]

I am going to close this for now, but feel free to ask for it to be re-opened if someone figures out how to make it work on low-RAM processors.