Repository navigation
flash-start-address put into sector start address #16
Description
If I start a new project with
cargo generate gh:probe-rs/flash-algorithm-template --name=algotest \
-d target-arch=thumbv7em-none-eabihf \
-d ram-start-address=0x20000000 \
-d ram-size=0x20000 \
-d flash-size=0x8000000 \
-d flash-page-size=0x100 \
-d flash-sector-size=0x10000 \
-d empty-byte-value=0xffI see whatever I enter into flash-start-address ends up as the first (and only) sector start address in main.rs in line 18: sectors: [{address: ### }], which is wrong, because this is asserted to be zero here, as I learned here: #12 (comment).
In my opinion, the flash-start-address is supposed to only end up in template.yaml in line 20 Nvm/range/start and in main.rs in line 12: flash_address.
Activity
Yatekii commentedon Nov 21, 2024
I don't believe this is incorrect.
I believe the assert is incorrect. It is ARM specific. Flash sectors can be mapped to any address space.
pkoevesdi commentedon Nov 22, 2024
@9names, could you look at it again?
It was your comment where I learned it from. #12
My opinion: this is not the address where the flash gets mapped to, it's the start address of it's own memory area, and I can't really imagine, that this doesn't start at 0x0 inside any chip. And even if, it wouldn't necessarily start at the same address as where if gets mapped to inside the MCU.
But little do I know....
9names commentedon Nov 22, 2024
@Yatekii if you look at the example here, you can see a flash algo targetting flash at 0x40000. You can see that the first set of sectors start at 0x0.
The assert would accept this algorithm.
If we consider this example to be correct, then the template is wrong and target-gen's assert is correct.
Yatekii commentedon Nov 22, 2024
But why would the sector point to 0 if the flash is not there? I feel like that might just be an assumption rather than anything else.
9names commentedon Nov 22, 2024
It's not really saying address zero though. It's algo base address (0x40000) + offset (0x0).
Yes, I agree that is strange when the algos themselves all take absolute physical addresses.
Yes, I am making an assumption that the reference example implementation was written this way specifically to convey this information. The choice of 0x40000 for the algo flash address is odd enough for me to consider it contrived.
We could look at what mcu vendors have done when they encountered this issue if we want to confirm what the de-facto standard is here.
Yatekii commentedon Nov 22, 2024
Ah, sorry, I meant that the flash algo example makes the assumption that flash is always at 0.
Let's investigate :)
pkoevesdi commentedon Nov 22, 2024
@9names, did You mix up a line here? I see the device start address 0x00000000. So, this example doesn't proof anything in our discussion here, since we can't see in the example, whether the sector start adress is absolute or relative.
Still, I'm totally sure, as You are, it is relative.
I think, some of the misunderstanding also has something to do with this:
The Open-CMSIS spec has nothing to do with memory-mapping or any MCU-internal adress space. It's purely specifying functions to write, erase, verify data from external flash. Whether this happens by some low-level SPI commands, or some MCU-internal diver with memory mapping, doesn't matter, this interface spec is supposed to be agnostic of that. That's why You'll find nothing there about MCU-internally mapped memory addresses and I think in the example, even the
Device Start Addressis inside the external flash's address space.(As a matter of fact, this being-agnostic is what
probe-rsbreaks with it's own verify function, ignoring the Open-CMSIS-specified, user-written one, see here: probe-rs/probe-rs#2617)pkoevesdi commentedon Nov 22, 2024
One thing I found that supports our thesis:
a flash algo by @huming2207, also setting the sector address to 0x0, while the flash address ist 0x08000000, see https://github.com/huming2207/stm32wle5-flash-algo/blob/master/src/main.rs
9names commentedon Nov 22, 2024
No, I was viewing that example on mobile and the comments are displayed on the next line instead of inline. Oops.