Fix F4x7vx definitions

[fpistm]

Issue reported by @stas2z
#937 (comment)

Thanks

[stas2z]

One little note about ccm ram since you are included it to loader script and defined a region

At least at f4, it have an issue with dfu upload
After upload board can stuck in hardfault when accessing ccm cuz dfu bootloader disable ccm clock, so you need to enable ccm clock manually in your code to prevent it.
Simpliest way is to include __HAL_RCC_CCMDATARAMEN_CLK_ENABLE() call to SystemClock_Config

[fpistm]

@stas2z
I used Black F407 several time with DFU and doesn't met this issue.
Do you used a custom DFU command and /or tools ?

[stas2z]

@stas2z
I used Black F407 several time with DFU and doesn't met this issue.
Do you used a custom DFU command and /or tools ?

Have you accessed ccm on it? You can simply check this issue, just define estack to ccm origin+0x10000, upload, and upload it again, it will stuck until reset
Ive tried cubeprog and dfu-util, same issue

[fpistm]

Ok this is because you specifically access it 😉
By default this is not used as nothing is store to it.

[stas2z]

Sure, as i said "can stuck in hardfault when accessing ccm"
I mentioned this issue cuz you added this section, so anyone who will try to utilize defined ccm section will face this issue with dfu 😬

[stas2z]

Really, im serious, i think it's a bad idea to provide support for this F4x5/7 feature and miss simple issue which can cause serious headache (believe me, i spent a few hours trying to find out whats wrong with it)
CCM is a huge part of memory (half of RAM), it's fast, and it is a nice place for stack or FreeRTOS stack (heap1/4/5 with user defined ucHeap @ CCM) or some kind of framebuffer (in case you are not going to use DMA as DMA have no access to CCM)

[fpistm]

so you advise to not add it to the linker script ?

[stas2z]

so you advise to not add it to the linker script ?

as an option
but better to add __HAL_RCC_CCMDATARAMEN_CLK_ENABLE to "affected" variants clock config
as it enabled by default after reset it will not cause any additional drain, but it will fix issue with dfu bl disabling it

[fpistm]

This should be OK now.
Some linker script defined CCMRAM while they do not have it.
I guess @MCUdude copy the linker script across the generic F4 variant?

[stas2z]

Feeling myself boring, but, are you sure ccm memory have to be defined with (xwr) attr?
Afaik ifor f4x5/7 it connected to d-bus only and can't be used to execute code 😬
Ive seen cube generates ld script with xwr also, but...

[fpistm]

Feeling myself boring, but, are you sure ccm memory have to be defined with (xwr) attr?
Afaik ifor f4x5/7 it connected to d-bus only and can't be used to execute code 😬
Ive seen cube generates ld script with xwr also, but...

No worries 😉
Honestly, in a general way I trust the cube (even if sometimes there are some bugs 😝 ).

[fpistm]

I've fixed it.

[MCUdude]

I guess @MCUdude copy the linker script across the generic F4 variant?

I did, and it has worked on all the hardware I own (well, except for the F407). However, it would be great if the Arduino_Tools repo could provide the correct linker scripts for each target, just like it contains PeripheralPins.c and PinNamesVar.h for every variant

[fpistm]

Arduino_Tools repo could provide the correct linker scripts for each target, just like it contains PeripheralPins.c and PinNamesVar.h for every variant

Unfortunately, It could not as there is no access to the linker script generator. If the Cube MX had a CLI it would be easy.