Provides common Nvmc functionality

[huntc]

The embedded-storage traits are implemented to provide a higher-level abstraction for reading and writing from/to flash storage. In the first instance, support is provided for the nRF52 boards and the nRF9160, but other boards should be relatively easy to support if required in the future.

Sample usage of writing to flash given some 32 bit aligned slice of bytes:

// Erase a page
let _ = nvmc.try_erase(0, 4096);

// Write the 32 bit aligned slice
let _ = nvmc.try_write(0, some_u8_slice_on_32_bit_bounds);

An example of establishing the Nvmc on the nRF9160:

let mut nvmc = Nvmc::new(board.NVMC_NS, unsafe { &mut CONFIG });

...where CONFIG points to flash:

extern "C" {
    #[link_name = "_config"]
    static mut CONFIG: [u32; 1024];
}

...which can be expressed in a memory layout:

MEMORY
{
  /* NOTE 1 K = 1 KiBi = 1024 bytes */
  FLASH : ORIGIN = 0x00040000, LENGTH = 764K
  CONFIG : ORIGIN = ORIGIN(FLASH) + LENGTH(FLASH), LENGTH = 4K /* 4K is the flash page size */
  RAM : ORIGIN = 0x20020000, LENGTH = 128K
}

_config = ORIGIN(CONFIG);

Testing on the nRF52840 device can be achieved via cargo test --test nvmc from within the nrf52840-hal-tests folder.

Fixes #336

TODO:

• Implement the ReadNorFlash methods
• Implement the NorFlash methods
• Provide an Instance for the nRF52840
• Provide an Instance for the nRF9160
• Provide a nvmc module in nrf52840-tests for the new abstraction
• Write some more tests to test some boundary conditions
• Go through the code finely and compare it again with the nrfx library
• Provide an example of reading, writing and erasing from/to storage

[huntc]

titanclass/thingy91-lorawan-nbiot@4a9f673 shows the positive impact of this abstraction.

[jonas-schievink]

I'm not sure how you're planning on using this, but if you plan on offering non-blocking APIs we need to make sure this is mem::forget-safe (presumably by making it 'static)

Also some rationale on why this is const-generic instead of a dynamic slice would be nice, and why this is using u32 instead of u8 as the element type – does the NVMC have alignment requirements?

[Dirbaio]

Yes, writes must be aligned to u32. I agree on the const generics though, a dynamic slice seems simpler.

Also, I'm not sure if there's UB issues with having a &mut to the data while you modify it / erase it through magic register writes...?

[huntc]

I'm not sure how you're planning on using this, but if you plan on offering non-blocking APIs we need to make sure this is mem::forget-safe (presumably by making it 'static)

Commit 70aad94 makes its 'static.

[huntc]

Also some rationale on why this is const-generic instead of a dynamic slice would be nice.

Commit 70aad94 changes this to a dynamic slice. Dunno what I was thinking. :-)

[huntc]

Also, I'm not sure if there's UB issues with having a &mut to the data while you modify it / erase it through magic register writes...?

I may not fully understand the question. However, the data isn't actually modified via registers... the NVMC is put into various modes and then regular memory operations ensue.

[Dirbaio]

I'm not sure if these methods are needed. I'd just do the #[cfg]s in the logic above, which imo is much simpler.

[huntc]

Commit c71362c attends to this.

[huntc]

Commit 7958ca2 reverts back to the trait methods because there is no common type representing the NVMC configuration. For the 52840, we have the CONFIG type which is a register of a _CONFIG struct. For the 9160 it is CONFIGNS and _CONFIGNS respectively.

[huntc]

Actually, commit e0e4482 figures it out. Deref FTW.

[huntc]

Commit 90b8818 also adds 52840 considerations.

[huntc]

@jonas-schievink @Dirbaio We now have tests for the NVMC via nRF52840-hal-tests, and things appear to be working! I want to go through things finely before converting from a draft PR, and write an example. I also want to do some boundary checks via my tests. Your feedback is appreciated!

[huntc]

This PR is complete and ready for a thorough review.

[jonas-schievink]

bors r+

[bors]

Build succeeded:

• ci