(embassy-rp): Implementation of generic flash mutation access #951

MathiasKoch · 2022-09-16T10:47:57Z

I have attempted to utilize the work done in rp2040-flash by implementing embedded-storage traits on top, for RP2040.

Concerns:

Should the DMA be paused where I have put a FIXME note? DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?
Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?
Any good way of making this configurable over FLASH_SIZE, WRITE_SIZE and ERASE_SIZE without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?

EDIT:
I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact Multiwrite capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time.

I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style.

Ping @Dirbaio

… for RP2040

Dirbaio · 2022-09-16T13:46:57Z

Should the DMA be paused

Oof this is cursed. I guess yes, or this will be a problem when DMAing from flash.

If so, how to properly do that without have control over the peripheral for the DMA channels?

If the flash code globally disables irqs and stops the other core you have the guarantee that no other code will race you, so you can go ahead and do it unsafely I guess...

And if so, I assume we should only re-enable/unpause the ones that were enabled before?

Yes...

Also, are we sure EN=0/EN=1 pauses/resumes the channel fully seamlessly?

Alternatively we can disallow DMAing from flash... nRF has this limitation in hardware and it's not that bad, it means you have to copy through a RAM buffer though. Perhaps it could be feature-gated, so you can either "DMA from flash" OR "write to flash", but not both in the same binary...

Should I make sure core2 is halted as part of this code? I

In the final version yes, but I'd say it's OK to not do it for now since we don't support muticore yet.

Note that code resets core2, we want to pause it instead. It'd have to send an irq to the other core (using the FIFO maybe) so that the other core "parks" itself in a RAM irq handler. Also note it's possible to do flash ops from core2, in this case it should park core1 😓 .

Any good way of making this configurable over FLASH_SIZE, WRITE_SIZE and ERASE_SIZE without doing it as generics or parameters

Cargo features with a range of possible options? :P They're always powers of 2 so there shouldn't be too many "reasonable" options...?

MathiasKoch · 2022-09-16T14:54:19Z

Also, are we sure EN=0/EN=1 pauses/resumes the channel fully seamlessly?

From the RP2040 datasheet:

DMA Channel Enable.
When 1, the channel will respond to triggering events,
which will cause it to become BUSY and start transferring
data. When 0, the channel will ignore triggers, stop issuing
transfers, and pause the current transfer sequence (i.e.
BUSY will remain high if already high)

As I read that, it actually fully pauses any ongoing transfer, so I don't think this is too bad.

In the final version yes, but I'd say it's OK to not do it for now since we don't support muticore yet.

Note that code resets core2, we want to pause it instead. It'd have to send an irq to the other core (using the FIFO maybe) so that the other core "parks" itself in a RAM irq handler. Also note it's possible to do flash ops from core2, in this case it should park core1.

Noted.

Cargo features with a range of possible options? :P They're always powers of 2 so there shouldn't be too many "reasonable" options...?

Hmm, yeah. I'm not super fond of that way of doing it. It just doesn't seem to scale very well :(

lulf · 2022-09-19T07:36:25Z

I have attempted to utilize the work done in rp2040-flash by implementing embedded-storage traits on top, for RP2040.

Concerns:

1. Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?

2. Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?

3. Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?

Although a slightly different situation, I've had a similar dilemma in embassy-boot generalizing these, and ended up using const generics for them. What about a combination that allows both uses: a GenericFlash using const generics, and a type alias Flash based on cargo features? Or would that be too confusing?

MathiasKoch · 2022-09-19T08:55:52Z

I have attempted to utilize the work done in rp2040-flash by implementing embedded-storage traits on top, for RP2040.

Concerns:
1. Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?

2. Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?

3. Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?
Although a slightly different situation, I've had a similar dilemma in embassy-boot generalizing these, and ended up using const generics for them. What about a combination that allows both uses: a GenericFlash using const generics, and a type alias Flash based on cargo features? Or would that be too confusing?

That was actually exactly what I was thinking about.
Either chip specific exports like boot2 does for their bootloaders, or '1M_4_1' kind of definitions, where 'FLASH-SIZE_ERASE-SIZE_READ-SIZE'

Compiler will infer a different lifetime for BootFlash than for the borrowed flash, which makes it require more type annotations than if it was just owning the type. Since it doesn't really matter if it owns or borrows in practical use, change it to own so that it simplifies usage.

Fixes a bug in the partition assertions that ensures that the state page(s) have enough space for 2x active partition range. Add unit test to verify that panic is observed.

Removes feature(generic_associated_types)

… for RP2040

…ata functions, which are now part of this HAL as well

Dirbaio · 2022-09-26T10:07:22Z

What about a combination that allows both uses: a GenericFlash using const generics, and a type alias Flash based on cargo features? Or would that be too confusing?

It should be one or the other. Having 2 ways of doing the same thing is very confusing.

MathiasKoch · 2022-09-26T10:35:32Z

Given the kind of extreme limitations of the rom-data flash API, that aims at wide flash support, my suggestion would be to make a repo similar to https://github.com/rp-rs/flash-algo where we can implement a few different implementations (QSPI, Dual-SPI, SPI) in various configurations, compile and link them fully for RAM, and then include_bytes() one of them similarly to https://github.com/rp-rs/rp2040-boot2.

Then we can do fallback to the flash API in rom-data, if users do not wish the added flash size of an optimized flash API.

EDIT: Limitations here being the WRITE_SIZE = 256

Parameters
flash_offs Flash address of the first byte to be programmed. Must be aligned to a 256-byte flash page.
data Pointer to the data to program into flash
count Number of bytes to program. Must be a multiple of 256 bytes (one page).

W.R.T flash configurations & cargo features vs const generics, how about adding a "custom" peripheral for flash, such that you can only instantiate it once (panic on re-entrance), where you can pass flash-size, erase-size etc., and then you would have to pass around the flash struct like all other microcontrollers?

Thoughts @Dirbaio @lulf ?

Dirbaio · 2022-09-26T10:40:55Z

Sounds good to me! 👍 I think having to write RAM-linked "flash driver" blobs is inevitable given the ROM limitations...

adding a "custom" peripheral for flash, such that you can only instantiate it once (panic on re-entrance), where you can pass flash-size, erase-size etc., and then you would have to pass around the flash struct like all other microcontrollers?

Not sure what you mean by "custom"? I'd make a normal FLASH peripheral (just the singleton struct, no functionality) and then a Flash driver that you pass all that config when creating it. If we do this, the API would have the same structure as any other peripheral.

MathiasKoch · 2022-09-26T10:45:22Z

Not sure what you mean by "custom"? I'd make a normal FLASH peripheral (just the singleton struct, no functionality) and then a Flash driver that you pass all that config when creating it. If we do this, the API would have the same structure as any other peripheral.

By custom i just meant that it does not come from a pac peripheral. Not sure what the requirements are for the peripheral! macro in embassy?

Dirbaio · 2022-09-26T10:55:30Z

Ah! then all our peripherals are already "custom". They're all invented by the HAL, we don't use the PAC ownership model. (rp and stm32 PACs don't have owned singletons at all because they're generated by chiptool. nrf PACs do because we're using the nrf-rs ones, but we just ignore them)

MathiasKoch · 2022-09-27T03:33:04Z

Perhaps it would make sense to just have the RAM-blobs implement the CMSIS-Pack ABI? That way it would be re-usable by probe-rs once they figure out how they want to tackle probe-rs/probe-rs#1212

MathiasKoch · 2022-10-27T05:13:46Z

@Dirbaio Ready for merge!

In case you didn't see it on matrix, I figured out the issue was due to the RTT header residing in flash:

debugger looking for the RTT header which caused the flash access which in turn caused a fault?
I had the same issue with rp2040-flash, with the following workaround: https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L88-L92

For defmt-rtt, it should be fixed with version 0.4.0, which includes knurling-rs/defmt#683

Dirbaio

bors d+

bors · 2022-10-27T07:55:14Z

✌️ MathiasKoch can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

MathiasKoch · 2022-10-27T09:35:33Z

bors r+

MathiasKoch · 2022-10-27T09:35:43Z

bors r-

bors · 2022-10-27T09:35:45Z

Canceled.

MathiasKoch · 2022-10-27T09:37:07Z

bors r+

951: (embassy-rp): Implementation of generic flash mutation access r=MathiasKoch a=MathiasKoch I have attempted to utilize the work done in `rp2040-flash` by implementing `embedded-storage` traits on top, for RP2040. Concerns: 1. ~~Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?~~ 2. ~~Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?~~ 3. ~~Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?~~ **EDIT:** I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact `Multiwrite` capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time. I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style. Ping `@Dirbaio` Co-authored-by: Mathias <mk@blackbird.online> Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl> Co-authored-by: Joakim Hulthe <joakim@hulthe.net> Co-authored-by: Alex Martens <alex@thinglab.org> Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com> Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

bors · 2022-10-27T09:46:20Z

Build failed:

all

lulf

Awesome work 🚀

MathiasKoch · 2022-10-27T10:41:27Z

bors r+

951: (embassy-rp): Implementation of generic flash mutation access r=MathiasKoch a=MathiasKoch I have attempted to utilize the work done in `rp2040-flash` by implementing `embedded-storage` traits on top, for RP2040. Concerns: 1. ~~Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?~~ 2. ~~Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?~~ 3. ~~Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?~~ **EDIT:** I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact `Multiwrite` capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time. I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style. Ping `@Dirbaio` Co-authored-by: Mathias <mk@blackbird.online> Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl> Co-authored-by: Joakim Hulthe <joakim@hulthe.net> Co-authored-by: Alex Martens <alex@thinglab.org> Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com> Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

bors · 2022-10-27T10:45:42Z

Build failed:

all

MathiasKoch · 2022-10-27T11:01:22Z

bors r+

951: (embassy-rp): Implementation of generic flash mutation access r=MathiasKoch a=MathiasKoch I have attempted to utilize the work done in `rp2040-flash` by implementing `embedded-storage` traits on top, for RP2040. Concerns: 1. ~~Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?~~ 2. ~~Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?~~ 3. ~~Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?~~ **EDIT:** I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact `Multiwrite` capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time. I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style. Ping `@Dirbaio` Co-authored-by: Mathias <mk@blackbird.online> Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl> Co-authored-by: Joakim Hulthe <joakim@hulthe.net> Co-authored-by: Alex Martens <alex@thinglab.org> Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com> Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

bors · 2022-10-27T11:12:34Z

Build failed:

all

MathiasKoch · 2022-10-27T11:48:34Z

I don't understand why the bors test is failing?
It works 100% of the times with teleprobe locally?
@Dirbaio

Dirbaio · 2022-10-27T11:51:31Z

the CI has a Pico W, not sure if it matters..?

MathiasKoch · 2022-10-27T14:23:04Z

Hmm, can't see how that should matter :/

MathiasKoch · 2022-10-28T06:17:36Z

Hmm. I just tested it on a Pico I had lying around here (non W version), and it works great there as well. Teleprobe tests pass 100% of times.

Not sure what is different with the CI, but I don't have a Pico W to test it on :(

Dirbaio · 2022-10-28T11:59:34Z

bors r+

951: (embassy-rp): Implementation of generic flash mutation access r=Dirbaio a=MathiasKoch I have attempted to utilize the work done in `rp2040-flash` by implementing `embedded-storage` traits on top, for RP2040. Concerns: 1. ~~Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?~~ 2. ~~Should I make sure core2 is halted as part of this code? I am not sure if https://github.com/jannic/rp2040-flash/blob/ea8ab1ac807a7ab2b28a18bb5ca2e42495bb744d/examples/flash_example.rs#L103-L109 is heavy/slow code to run?~~ 3. ~~Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?~~ **EDIT:** I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact `Multiwrite` capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time. I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style. Ping `@Dirbaio` Co-authored-by: Mathias <mk@blackbird.online> Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl> Co-authored-by: Joakim Hulthe <joakim@hulthe.net> Co-authored-by: Alex Martens <alex@thinglab.org> Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com> Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

bors · 2022-10-28T12:10:06Z

Build failed:

all

Dirbaio · 2022-10-28T12:19:40Z

bors r+

bors · 2022-10-28T12:30:32Z

Build succeeded:

all

First iteration attempt on implementing generic flash mutation access…

feb840c

… for RP2040

MathiasKoch force-pushed the embassy-rp/flash branch from a9052dd to feb840c Compare September 16, 2022 11:20

FrozenDroid and others added 17 commits September 23, 2022 07:58

make State::new() const, consistent with others

7bb9620

Add .into_inner() and .get_mut() to Mutex

e5af4c4

Make rustfmt happy

3f672c8

Feature-gate time-driver in embassy-rp

f46b838

Add time-driver feature to docs

5d1576e

rp: remove extraneous newlines in logs

8129839

rp: fix async SPI read and write

c145274

rp: let SPI RX overflow during async write

4322293

Take into account size of revert index

334dfcd

Fixes a bug in the partition assertions that ensures that the state page(s) have enough space for 2x active partition range. Add unit test to verify that panic is observed.

Implement RealTimeClock for embassy-rp

0db1332

Update Rust nightly.

7412a85

Removes feature(generic_associated_types)

Replace futures::future::poll_fn -> core::future::poll_fn.

2fed9f9

Replace futures::future::join -> embassy_futures::join::join.

4f33cc5

Add RP2040 ROM functions and intrinsics aliases

816778e

First iteration attempt on implementing generic flash mutation access…

9d674f0

… for RP2040

Drop rp2040-flash as dependency, as they pull in rp2040-hal for rom-d…

18dc0de

…ata functions, which are now part of this HAL as well

Rebase on master

7ee7109

Rebase on master

c871fe0

Dirbaio approved these changes Oct 27, 2022

View reviewed changes

Remove unused imports from test

a7b90c7

lulf reviewed Oct 27, 2022

View reviewed changes

Add delay to flash test to allow time to parse RTT header

bc21b6e

MathiasKoch force-pushed the embassy-rp/flash branch from 1b727a0 to bc21b6e Compare October 27, 2022 10:49

bors bot merged commit e7fdd50 into embassy-rs:master Oct 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

(embassy-rp): Implementation of generic flash mutation access #951

(embassy-rp): Implementation of generic flash mutation access #951

MathiasKoch commented Sep 16, 2022 •

edited

Loading

Dirbaio commented Sep 16, 2022

MathiasKoch commented Sep 16, 2022

lulf commented Sep 19, 2022

MathiasKoch commented Sep 19, 2022

Dirbaio commented Sep 26, 2022

MathiasKoch commented Sep 26, 2022 •

edited

Loading

Dirbaio commented Sep 26, 2022 •

edited

Loading

MathiasKoch commented Sep 26, 2022

Dirbaio commented Sep 26, 2022

MathiasKoch commented Sep 27, 2022

MathiasKoch commented Oct 27, 2022

Dirbaio left a comment

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

lulf left a comment

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

Dirbaio commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

MathiasKoch commented Oct 28, 2022

Dirbaio commented Oct 28, 2022

bors bot commented Oct 28, 2022

Dirbaio commented Oct 28, 2022

bors bot commented Oct 28, 2022

(embassy-rp): Implementation of generic flash mutation access #951

(embassy-rp): Implementation of generic flash mutation access #951

Conversation

MathiasKoch commented Sep 16, 2022 • edited Loading

Dirbaio commented Sep 16, 2022

MathiasKoch commented Sep 16, 2022

lulf commented Sep 19, 2022

MathiasKoch commented Sep 19, 2022

Dirbaio commented Sep 26, 2022

MathiasKoch commented Sep 26, 2022 • edited Loading

Dirbaio commented Sep 26, 2022 • edited Loading

MathiasKoch commented Sep 26, 2022

Dirbaio commented Sep 26, 2022

MathiasKoch commented Sep 27, 2022

MathiasKoch commented Oct 27, 2022

Dirbaio left a comment

Choose a reason for hiding this comment

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

lulf left a comment

Choose a reason for hiding this comment

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

bors bot commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

Dirbaio commented Oct 27, 2022

MathiasKoch commented Oct 27, 2022

MathiasKoch commented Oct 28, 2022

Dirbaio commented Oct 28, 2022

bors bot commented Oct 28, 2022

Dirbaio commented Oct 28, 2022

bors bot commented Oct 28, 2022

MathiasKoch commented Sep 16, 2022 •

edited

Loading

MathiasKoch commented Sep 26, 2022 •

edited

Loading

Dirbaio commented Sep 26, 2022 •

edited

Loading