Add NRF S140 7.0.1

[xobs]

This patch adds S140 v7.0.1, which Nordic says is the first version that supports the nRF52833.

[dhalbert]

Just to confirm, you loaded the 7.0.1 SD on your board as well when you tested?

[xobs]

Yes, I've updated the bootloader as well (see https://github.com/simmel-project/bootloader) and I'm loading 7.0.1 of the SD.

[hathach]

the flash size for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.

[dhalbert]

the flash size for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.

I worried about this too, but it turns out I parameterized it when I parameterized the .ld file:

circuitpython/ports/nrf/boards/common.template.ld

Line 11 in 51dbe91

FLASH_SD (rx) : ORIGIN = ${SD_FLASH_START_ADDR}, LENGTH = ${SD_FLASH_SIZE}

[hathach]

the flash size for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.

I worried about this too, but it turns out I parameterized it when I parameterized the .ld file:

circuitpython/ports/nrf/boards/common.template.ld

Line 11 in 51dbe91

FLASH_SD (rx) : ORIGIN = ${SD_FLASH_START_ADDR}, LENGTH = ${SD_FLASH_SIZE}

that is too smart, Dan 💯

[dhalbert]

This looks good!

In the long run it might be nice to use a submodule for the SD header files, though I'm not sure how we would have two versions available at once.

I will not merge yet pending any comments by anyone else.

[xobs]

That definitely would explain why my flash space shrunk by about 4096 bytes when I made the change.

[hathach]

That definitely would explain why my flash space shrunk by about 4096 bytes when I made the change.

Did you change the bootloader knowledge of application size and starting address !!!

[xobs]

I'm unsure of how it worked, but somehow it did. I have a feeling there's something in the UICR region that told it where to go, or possibly based on macros such as SD_SIZE_GET(MBR_SIZE) that are imported from the nrf headers.

[hathach]

I'm unsure of how it worked, but somehow it did. I have a feeling there's something in the UICR region that told it where to go, or possibly based on macros such as SD_SIZE_GET(MBR_SIZE) that are imported from the nrf headers.

No it is not that good https://github.com/simmel-project/bootloader/blob/simmel/src/usb/uf2/uf2cfg.h#L12
I am actually updating the bootloader repo for supporting self-updating with uf2 and also cross-version v6 <-> v7 support. I am not sure why it works out so well for you, maybe it is worth further analyzing.

@dhalbert maybe it is a good reason for us to upgrade to v7 :D . I will resume to bootloader work shortly.

[tannewt]

I'm totally game for this! Do we need to update the UF2 bootloader along with it?

[dhalbert]

I'm totally game for this! Do we need to update the UF2 bootloader along with it?

Yes, the bootloader includes the SoftDevice. So if we update CPy to v7.0.1, the user has to update both, and can't roll back just one. So it's kind of a big deal.

We don't yet a have self-updater for the bootloader: it's hard because once the bootloader protection is set, you can't undo it to write the bootloader. We could fix that in a new bootloader, but not in the current one, I think. So I think the user has to do a DFU or SWD update at least once.

[xobs]

No it is not that good

I see. In that case, I assume it worked because 0x26000 is within the region that's reserved for BLE pairings on my board, and I didn't pair any BLE devices. I've since replaced it with a macro, so now it should be loading at the correct address: https://github.com/simmel-project/bootloader/blob/simmel/src/usb/uf2/uf2cfg.h#L12

I think that updating the bootloader and softdevice is a major enough event that it's not worth it for most customers. I saw all sorts of hooks inside the bootloader to update the SD, but I've mostly patched them out. It's not possible to update SD via UF2.

There shouldn't be a problem with having two different versions of the SD, especially since they seem to be mostly API (and ABI?) compatible. The risk comes mostly in using API calls that only exist in one version of the SDK, but that's what CI is for right?

[xobs]

Oh. No, the reason why it works is because UF2 encodes the address as part of the file, and the bootloader was just honoring the addresses generated by circuitpython. The invalid USER_FLASH_START address just means that the UF2 file is capable of overwriting the SD, but because circuitpython has the correct addresses it won't actually do so.

Also, my USER_FLASH_END variable is incorrect. And the UF2_FAMILY_ID is still 0xADA52840 even for nrf52833. Hmm...

[hathach]

Oh. No, the reason why it works is because UF2 encodes the address as part of the file, and the bootloader was just honoring the addresses generated by circuitpython. The invalid USER_FLASH_START address just means that the UF2 file is capable of overwriting the SD, but because circuitpython has the correct addresses it won't actually do so.

Also, my USER_FLASH_END variable is incorrect. And the UF2_FAMILY_ID is still 0xADA52840 even for nrf52833. Hmm...

Yeah, exactly, the uf2 isn't included the address that overwrite the portion of SD. But it could run into issue with uf2 from another board such as 52840. Regarding the self-updater for bootloader, it is actually possible, Dan thought I implemented write protection for bootloader, but hehe I am too lazy and only open an issue for that and didn't do anything just yet. Therefore it is entirely possible, in fact I was working on self updater with uf2 for bootloader here before switching to esp32s2 port

https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/self-uf2/src/usb/uf2/uf2cfg.h

One of the issue with update bootloader is making sure it will only flash the bootloader of that particular board e.g feather_nrf52840 express should reject the CLUE bootloader u2f. I intend to include the VID/PID to uf2 file but didn't find a std way to do so. @dhalbert @xobs we can move the discussion with related uf2 updater to its own issue here adafruit/Adafruit_nRF52_Bootloader#24 if you have more idea on how it should be done.

[xobs]

This patch does two things:

1. Add s140 v7.0.1 as an option to build, and
2. Switch nrf52833 to use v7.0.1

Since this is the minimum supported version for that chip, and while 6.1.1 works (but is not supported by the vendor), are there any blockers for integrating this into circuitpython?

There's a lot of discussion here about how to update nrf52840 boards, but I suspect that should be a separate topic, since nrf52833 shouldn't ever really be running v6.1.1.

[dhalbert]

It's fine! I was just waiting for extra vetting, but I see no reason not to proceed.