would it be of use if I generated some missing "default linker script"'s

[Alextrical]

Hi All

I was looking through the list of supported 'Generic' chips supported, and was wondering if it would be of any use if I went through and generated the missing "default linker script" files as per the Wiki?

I'm assuming that one linker file would be needed for the Chip Part Number, ignoring the Flash memory and Package variants? i.e. only one Linker file would be needed for the set of the following:
STM32F207VC
STM32F207VE
STM32F207VF
STM32F207VG

Kind regards
Alextrical

[Alextrical]

Here is a list of the chips that STM32 make vs supported in STM32Duino https://drive.google.com/file/d/1-HgvTQ ... sp=sharing

I will have a look at making the Linker scripts for the larger groups of Parts missing support to start with, and see how long that takes to make those files. Would someone be able to guide me on how best to get these files available to the project?

[Alextrical]

Here is a link to the Linker Scripts / LD files created with STM32CubeMX
https://github.com/alextrical/STM32-linker-scripts

[ABOSTM]

HI @Alextrical ,
Thanks for your proposal, as I said in https://github.com/stm32duino/Arduino_C ... /pull/1781
Generally when adding new generic variant, we also update SystemClock_Config() in generic_clock.c: https://github.com/stm32duino/wiki/wiki ... figuration
so that, instead of using reset clock configuration (which is slow), we use PLL with the max frequency supported, and if supported, we configure USB clock 48MHz (so that clock is ready to support USB).

I'm assuming that one linker file would be needed for the Chip Part Number, ignoring the Flash memory and Package variants?

I fact, one and only one linker file is necessary per directory, but it need abstraction on RAM / FLASH like described in wiki (LD_MAX_DATA_SIZE, LD_MAX_SIZE, ... coming from boards.txt)
- RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 144K
- FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
+ RAM (xrw) : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE
+ FLASH (rx) : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET

Would someone be able to guide me on how best to get these files available to the project?

It seems you already find your way
but for those looking for help: https://github.com/stm32duino/wiki/wiki ... 28board%29

Having all linker files is great achievement, but we absolutely need RAM/FLASH abstraction.

@fpistm what is your feedback ?

[Alextrical]

Generally when adding new generic variant, we also update SystemClock_Config() in generic_clock.c: https://github.com/stm32duino/wiki/wiki ... figuration
so that, instead of using reset clock configuration (which is slow), we use PLL with the max frequency supported, and if supported, we configure USB clock 48MHz (so that clock is ready to support USB).

Ah, sorry about that, I will look into getting that change made, by looking through the guide that you have linked to, and let you know if I hit any walls while following it. This is why I asked for help, I knew I would have missed something while skimming the guide

I fact, one and only one linker file is necessary per directory, but it need abstraction on RAM / FLASH like described in wiki (LD_MAX_DATA_SIZE, LD_MAX_SIZE, ... coming from boards.txt)
- RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 144K
- FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
+ RAM (xrw) : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE
+ FLASH (rx) : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET

Having all linker files is great achievement, but we absolutely need RAM/FLASH abstraction.

I've also converted the files to follow that format, with bulk replace and a visual check of the ~270 files, and can post them on GitHub if you think that would be of use. Some of them didn't follow the above pattern, (i.e. RAM2) so I would try to separate them out to a separate folder

I will do as much as I can to try and get the G0 MCU's I've started work on finished off according to your advice, though I may have some questions about setting the clock frequency, I will know once I finish reading that guide

[fpiSTM]

Having all linker files is great achievement, but we absolutely need RAM/FLASH abstraction.

@fpistm what is your feedback ?

Hi, yes it is mandatory as several mcu are available per directory with different flash and RAM size.

[ABOSTM]

@fpistm,
Thanks for your reply,
Sorry I was not clear, I was more expecting feedback about having linker files without clock update, which is functional but far from performances.

[Alextrical]

I have tried to follow that part of the guide but have a couple of questions,

Go to Pinout tab, enable the desired peripherals which require specific clock configuration (not needed for peripherals clocked by HCLKx, or APBx clock): SDIO, USB, ... In this example only USB needs to be enabled as other peripherals default clock are correct by default.

Do we Only have to enable USB for all MCU families, or are there exceptions? If so how can we tell?

Try to set the CPU clock and HCLK to the maximum frequencies,

I can set the 'HCLK (MHz)' option, however I cannot see a option for 'CPU clock', not sure what I'm missing. Is it the same as 'SYSCLK'?https://drive.google.com/file/d/1s2nQPh ... sp=sharing

the one generated in src/main.c of the generated project.

Once I generate the project, the 'src' folder isn't generated. Please advise
https://drive.google.com/file/d/1iAYyPk ... sp=sharing

It is mandatory as several mcu are available per directory with different flash and RAM size.

That's fine, I understood that from the guide, that its one parameterised .ld file per folder group. I will upload the 270+ files to GitHub that have been converted to this format, if you would like.
How do you want me to deal with the .ld files that do not match the expected pattern, i.e. RAM1, RAM2, SRAM4, RAM_SHARED or CCMRAM?

e.g. STM32F205RBTx

Code: Select all

/* Memories definition */
MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = LD_MAX_DATA_SIZE
  RAM2    (xrw)    : ORIGIN = 0x2001C000,   LENGTH = 16K
  FLASH    (rx)    : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET
}

[Alextrical]

"Abstraction" files for the linker scripts I generated, are now all available in my GitHub repo.

Once I find out how to generate the Clock settings, I will start work on generating them.

[ABOSTM]

Do we Only have to enable USB for all MCU families, or are there exceptions? If so how can we tell?

Yes all, Exceptions are, of course, those not supporting USB.

I can set the 'HCLK (MHz)' option, however I cannot see a option for 'CPU clock', not sure what I'm missing. Is it the same as 'SYSCLK'?

Most of the time, CPU clock (or core clock) is the same than HCLK, but there are exceptions:
For example on STM32H747 there are 2 cores, with theyr respective CPU1 clock and CPU2 clock. CPU1 clock is different from HCLK.
https://i.postimg.cc/QMzqJ3bZ/STM32-H747-Clock.png

The point is to have the max frequency on core(s), and buses (AHBx, APBx).

Once I generate the project, the 'src' folder isn't generated. Please advise

I can't see the picture (I requested access), but the point is the following:
with cubeMX you generate the code of the project, within the generated project look for function void SystemClock_Config(void)

How do you want me to deal with the .ld files that do not match the expected pattern, i.e. RAM1, RAM2, SRAM4, RAM_SHARED or CCMRAM?

Hopping there is not too much of those, I think it should be handled manually.
For simplicity, in stm32duino, we generally do like this:
* when several RAM are adjacent, then we declare only one with the whole size. (size is declared in boards.txt)
* when several RAM are not adjacent, only one is declared (the biggest one)
Note this can still be customized on purpose by users.


One last advice, because we consider Generic boards, we cannot rely on external hardware,
so use of LSE/HSE is forbidden and replaced by internal oscillators LSI/MSI/HSI.