Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Incorrect memory sizes tracking issue #301

Closed
Dirbaio opened this issue Nov 1, 2023 · 12 comments
Closed

Incorrect memory sizes tracking issue #301

Dirbaio opened this issue Nov 1, 2023 · 12 comments
Labels
bug Something isn't working

Comments

@Dirbaio
Copy link
Member

Dirbaio commented Nov 1, 2023

If you've got a chip where the stm32-metapac/memory.x feature generates a wrong memory.x please post here.

Identified cases:

  • STM32G030K8 flash generates 32kb but has 64kb
  • STM32WL55JC ram generates 12kb but has 64kb
@Dirbaio Dirbaio mentioned this issue Nov 1, 2023
Closed
@Dirbaio Dirbaio added the bug Something isn't working label Nov 1, 2023
@TaylorCarpenter
Copy link
Contributor

STM32WB55VG ram generates 128kb but has 192kb.

@phycrax
Copy link
Contributor

phycrax commented Jan 29, 2024

STM32G030C8 flash generates 32kb but has 64kb

@trepidacious
Copy link

stm32g491re memory.x shows 32kb RAM, chip should have 112kb (3 blocks of 80, 16, 16)

@Dirbaio Dirbaio pinned this issue Feb 4, 2024
@Dirbaio
Copy link
Member Author

Dirbaio commented Feb 5, 2024 •
edited
Loading

STM32F303ZE says it has 64k but only has 48kb https://github.com/embassy-rs/stm32-data-generated/issues/1 nope, it's indeed 64k?
stm32u5a5zj says it has 32k but it has 2.5mb or something

@eZioPan
Copy link
Contributor

eZioPan commented Feb 7, 2024 •
edited
Loading

Chip Type memory.x DS Tab.2 Note
STM32F411RE RAM 64K 128 KB

markdown if need

|     Chip    |  Type  | memory.x | DS Tab.2  |        Note        |
| :---------: | :----: | :------: | :-------: | :----------------: |
| STM32XDDDXX |  RAM   |  ddd K   |  ddd KB   |                    |
|             | FLASH  |  ddd K   |  ddd KB   |                    |

@caleb-garrett caleb-garrett mentioned this issue Feb 11, 2024
Merged
@eZioPan
Copy link
Contributor

eZioPan commented Mar 5, 2024 •
edited
Loading

Chip Type memory.x DS Tab.2 Note
STM32H5[67]xx[IG] RAM 256 K 640 (256+64+320) KB

@Dirbaio
Copy link
Member Author

Dirbaio commented Mar 12, 2024

Chip Type memory.x actual Note
STM32F051R8T6 RAM 7 K 8 KB #437

@Dirbaio Dirbaio mentioned this issue Mar 12, 2024
Closed
@LorenzoCucchi
Copy link

Chip Type memory.x actual Note
STM32F756ZG RAM 320K 256K

64 K less since DTCM starting at 0x20000000 is not used, and RAM starts at 0x20010000.

@adri326
Copy link

adri326 commented Mar 22, 2024

Chip Type memory.x DS Tab.2 Note
STM32L4A6ZG RAM 320K 256K

Opposite issue to the one above: SRAM correctly starts at 0x2000_0000 up through 0x2004_0000, but the last 64K aren't available. According to the doc, there's a second SRAM2 memory device with 64K size, mapped both to 0x1000_0000 (which is present in the generated STM32L4A6ZG.json, although it has size 0), and to 0x2004_0000

@spcan
Copy link

spcan commented Mar 25, 2024

STM32F746ZG variant presents the same issue as the STM32F756 variant described before in this thread.

Chip Type memory.x Actual Note
STM32F746ZG RAM 320K 256K

64K less because DTCM should not be counted. RAM starts at 0x20010000 not at 0x20000000.

Consider separating SRAM1 (240K) and SRAM2 (16K).

Dirbaio added a commit that referenced this issue Apr 9, 2024
@Dirbaio
Manually maintain memory maps instead of parsing them from cubeprogdb.
5989c5e 
First step towards fixing #301

The cubeprogdb has turned out to be a quite bad data source. It's not granular
enough (it has one entry per chip die, not per chip) so the previous code joined
the data with the C headers and cubedb to fill in the gaps, essentialy "guessing"
stuff. This has been quite error prone (see #301) and hard to make fixes to.

Instead, we're going to manually maintain memory maps in a .rs file. This way, if
something is wrong we can simply go and fix it.

This commit just migrates the existing data, even if it's wrong. (it does fix
a few very minor mistakes). Next steps is actually fixing the memory maps.
@Dirbaio Dirbaio mentioned this issue Apr 9, 2024
Merged
Dirbaio added a commit that referenced this issue Apr 9, 2024
@Dirbaio
Manually maintain memory maps instead of parsing them from cubeprogdb.
8e26f36 
First step towards fixing #301

The cubeprogdb has turned out to be a quite bad data source. It's not granular
enough (it has one entry per chip die, not per chip) so the previous code joined
the data with the C headers and cubedb to fill in the gaps, essentialy "guessing"
stuff. This has been quite error prone (see #301) and hard to make fixes to.

Instead, we're going to manually maintain memory maps in a .rs file. This way, if
something is wrong we can simply go and fix it.

This commit just migrates the existing data, even if it's wrong. (it does fix
a few very minor mistakes). Next steps is actually fixing the memory maps.
@wagcampbell
Copy link
Contributor

As mentioned in the Matrix chat, seeing some incorrect sizes for the STM32U5 Family.

From the reference manual (RM0456):

Flash configuration:
RM0456, 7.3.1, Table 51., 52., 53.:
image
image
image

SRAM configuration:
RM0456, 6.3.1, Table 45
image

Also, from the product page:
image
image
image
image
image
image

I haven't studied other STM32 MCUs this closely, but is it unusual to have so many SRAM devices?

Up to seven SRAMs are embedded in the devices

I'm working on a fix, but thought I'd post this before getting ahead of myself.

@wagcampbell wagcampbell mentioned this issue Apr 11, 2024
Merged
@jamesmunns jamesmunns mentioned this issue Apr 12, 2024
Closed
@phycrax phycrax mentioned this issue Apr 17, 2024
Merged
@AdinAck AdinAck mentioned this issue May 14, 2024
Merged
@Dirbaio Dirbaio mentioned this issue May 24, 2024
Closed
@Dirbaio Dirbaio mentioned this issue Jun 7, 2024
Closed
42 tasks
@Dirbaio Dirbaio closed this as completed in 3eab5e1 Jun 8, 2024
@Dirbaio
Copy link
Member Author

Dirbaio commented Jun 8, 2024 •
edited
Loading

3eab5e1 fixes all issues reported here and more. I believe all stm32 memory maps are correct now.

If you find a new mistake, please open a new issue.

@Dirbaio Dirbaio mentioned this issue Jun 16, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@trepidacious @Dirbaio @eZioPan @adri326 @spcan @wagcampbell @LorenzoCucchi @phycrax @TaylorCarpenter