More memory.x examples for device families

[TomDeRybel]

Hello,
I think it would be useful to have a couple complete and documented memory.x examples in the hal crate (or the stm32-rs crate?), ideally one for each of the major device families. As a newbie, that would help.

I've gone ahead and wrote one for the STM32H735 family, attached.
memory_x.txt

While reading RM0468, it became clear that many of the memory sizes (aside from FLASH) in the example are very different. What is confusing is that the corresponding files generated by CubeMX again show completely different sizes vs what the reference manual suggests. All of this leaves me rather stumped, and I could not find much in the way of documentation on how to do this properly.

Hence the attempt and proposal. I am not sure about the alignments, or the sizes, or anything else. I've tested this with some code (not making use of any of the defined regions yet), and it compiles & runs.

Any feed-back is welcome. I'll improve the file accordingly and, if there is interest, will submit it as a PR.

[richardeoin]

The example memory.x file lives in this crate, so this is the right place to ask! The Reference Manual should be the source of truth for the memory layout, so I wouldn't pay too much attention to CubeMX unless you find additional evidence it matches with reality.

I think the memory map for the H735 sub-family diverges a bit more from the other three, so I'd definitely support a separate memory.x example with as much documentation as possible. At a quick glance, the attached file looks good!

For consistency it might make sense split up all 4 sub-families. You'd end up with something like:
memory_742_743_753_750.x
memory_745_755_747_757.x
memory_7A3_7B3_7B0.x
memory_725_735_730.x

It is possible to use a build.rs script to automatically select the right one when building the examples (see stm32f7xx_hal or stm32l0xx_hal). Probably that's a good idea, since it means the correct memory layout is being used for CI.

[TomDeRybel]

Thank you for the positive reply. I'll look into this later this week and will try to write those four sub-family files to submit them as a combined PR sometime next week.

The automatic build script approach does look elegant, but is above my skill level. (To complicate it even further, there are some register flags that can change the memory lay-out that would likely also need features to set, if going that far with it all.) I'll leave that to the experts.

[richardeoin]

I also spotted @adamgreig wrote a nice memory.x example for the dual core parts (745/755/747/757)! @adamgreig - any issue with using parts of your example here?

[adamgreig]

Of course, feel free to use any of it. It's a pretty rough example so it might benefit from some tidying up. I think the original memory.x with the other sections was probably cribbed from this repo anyway!

[TomDeRybel]

That's a nice example indeed. I'll definitely "borrow" from it. Except for the multi-core parts, all the other files are 80% done.