New method of chip support (STM32F446VET6)

[dream111119]

Hello, I want to develop a firmware for the STM32F446VE motherboard. How do I correctly add a new chip to support it?

[jaysuk]

you'll probably find that that chip doesn't have enough flash to support all the features, so as well as supporting the chip, you will have to slim down the firmware.

Thanks,

Jay

On Fri, 16 Apr 2021 at 08:24, dream111119 @.***> wrote:

Hello, I want to develop a firmware for the STM32F446VE motherboard. How do I correctly add a new chip to support it?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gloomyandy/RepRapFirmware/issues/83, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBUOG4KOKRJLDP5C6M3TI7Q4VANCNFSM43A7BH6Q .

[dream111119]

Thank you very much, my memory is 512K, I believe it can run most of the functions @jaysuk

[jaysuk]

ok, I take it you're looking at running it on a fysetc spider? best to wait for @gloomyandy to respond then.

Thanks,

Jay

On Fri, 16 Apr 2021 at 08:41, dream111119 @.***> wrote:

Thank you very much, my memory is 512K, I believe it can run most of the functions @jaysuk https://github.com/jaysuk

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gloomyandy/RepRapFirmware/issues/83#issuecomment-820984501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBSDBOBE4BVXT3WB3WDTI7S3ZANCNFSM43A7BH6Q .

[dream111119]

Yes, but how to add chip support, because I am still learning the firmware, there is no specific method yet. After I changed the startup file, the compiled firmware was 477K, and I felt that the firmware did not fill up the memory. It is currently running, and the indicator light flashes normally. But the serial port baud rate is wrong, it should be that the main frequency is not configured correctly, so I think it should be my method of adding the chip is wrong

[dream111119]

@jaysuk @gloomyandy

[dream111119]

I am looking forward to providing a specific method for adding a new chip, such as the STM32F446 chip, I can analyze the problems I am encountering now, thank you very much

[gloomyandy]

@dream111119 I'm not sure that trying to support the STM32F446VE makes sense. When you say that the size is 477K what version of the firmware are you building? The latest development WiFi build (which by default loads at address 0x08008000 (so we allow 32K for the bootloader) already uses flash memory up to 0x0808fecc which is a total of 543Kb of flash which means a total size (with the bootloader) of 575kBytes. It may be possible to squeeze this down to be below 512Kbytes but this does not really leave any room for future enhancements.

[dream111119]

Yes, I am using the newly developed wifi version, I only modified the ldscript.ld file in BIGTREE_SKR_PRO_1V1

FLASH (rx): ORIGIN = 0x8008000, LENGTH = 512K

After compiling, I was surprised to find that the firmware size is only 477K. After I upgrade the firmware, the USB connection function can be used normally, the gcode can send and receive normally, but the serial port 1 is abnormal (may be a configuration problem). I plan to configure the motherboard pins and then debug. Believe me, he can support STM32F446VE, and it works now.

At present, the price of STM32F407VGT6 is increasing very fast, and STM32F446 is relatively cheap. I believe it has promotion value.

At present, we need a way to increase the motherboard normally and avoid many detours. This will be perfect. Very grateful @gloomyandy

[dream111119]

`/*

---

**

File : LinkerScript.ld Abstract : Linker script for STM32F407VETx Device with 512KByte FLASH, 128KByte RAM Set heap size, stack size and stack location according to application requirements. Set memory bank area and size if external memory is used. Target : STMicroelectronics STM32 Distribution: The file is distributed as is, without any warranty of any kind.

---

@attention

© COPYRIGHT(c) 2014 Ac6

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of Ac6 nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

---

*/

/ Entry Point / ENTRY(Reset_Handler)

/ Highest address of the user mode stack / _estack = 0x20020000; / end of RAM / / Generate a link error if heap and stack don't fit into RAM / _Min_Heap_Size = 0x200;; / required amount of heap / _Min_Stack_Size = 0x400;; / required amount of stack /

/ Specify the memory areas / MEMORY { FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 512K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K }

/ Define output sections / SECTIONS { / The startup code goes first into FLASH / .isr_vector : { . = ALIGN(4); KEEP((.isr_vector)) / Startup code */ . = ALIGN(4); } >FLASH

/ The program code and other data goes into FLASH / .text ALIGN(4): { . = ALIGN(4); (.text) / .text sections (code) / (.text) / .text sections (code) / (.glue_7) / glue arm to thumb code / (.glue_7t) / glue thumb to arm code / *(.eh_frame)

KEEP (*(.init))
KEEP (*(.fini))

. = ALIGN(4);
_etext = .;        /* define a global symbols at end of code */

} >FLASH

/ Constant data goes into FLASH / .rodata ALIGN(4): { . = ALIGN(4); (.rodata) / .rodata sections (constants, strings, etc.) / (.rodata) / .rodata sections (constants, strings, etc.) / . = ALIGN(4); } >FLASH

.ARM.extab : { (.ARM.extab .gnu.linkonce.armextab.) } >FLASH .ARM : { __exidx_start = .; (.ARM.exidx*) __exidx_end = .; } >FLASH

.preinit_array : { PROVIDE_HIDDEN (preinit_array_start = .); KEEP ((.preinit_array)) PROVIDE_HIDDEN (preinit_array_end = .); } >FLASH .init_array : { PROVIDE_HIDDEN (init_array_start = .); KEEP ((SORT(.init_array.))) KEEP ((.init_array)) PROVIDE_HIDDEN (init_array_end = .); } >FLASH .fini_array : { PROVIDE_HIDDEN (fini_array_start = .); KEEP ((SORT(.fini_array.))) KEEP ((.fini_array)) PROVIDE_HIDDEN (fini_array_end = .); } >FLASH

/ used by the startup to initialize data / _sidata = LOADADDR(.data);

/ Initialized data sections goes into RAM, load LMA copy after code / .data : { . = ALIGN(4); _sdata = .; / create a global symbol at data start / (.data) / .data sections / (.data) / .data sections /

. = ALIGN(4);
_edata = .;        /* define a global symbol at data end */

} >RAM AT> FLASH

/_siccmram = LOADADDR(.ccmram);/

/ Uninitialized data section / . = ALIGN(4); .bss : { / This is used by the startup in order to initialize the .bss secion / _sbss = .; / define a global symbol at bss start / __bss_start__ = _sbss; (.bss) (.bss) (COMMON)

. = ALIGN(4);
_ebss = .;         /* define a global symbol at bss end */
__bss_end__ = _ebss;

} >RAM

/ User_heap_stack section, used to check that there is enough RAM left / ._user_heap_stack : { . = ALIGN(4); PROVIDE ( end = . ); PROVIDE ( _end = . ); . = . + _Min_Heap_Size; . = . + _Min_Stack_Size; . = ALIGN(4); } >RAM

/ Remove information from the standard libraries / /DISCARD/ : { libc.a ( ) libm.a ( ) libgcc.a ( * ) }

.ARM.attributes 0 : { *(.ARM.attributes) } }

`

[dream111119]

This is the content of the file I modified

[gloomyandy]

What version of the source are you compiling? What is the size of the firmware.bin that has been produced? All of the current release versions of the firmware that include WiFi support are larger than 500Kb, I'm struggling to understand how you can have a version that fits into 512Kb without making other changes. Have you made any other changes other than to the ld file? What is the command line you are using to build the firmware?

You should also examine the map file that will show you the load addresses of the various parts of the file, in particular it will show you the highest addresses being used.

[gloomyandy]

I'm also very confused by the linker file that you have posted. That does not seem to be based on either of the files that we currently use for release builds. In particular it seems to be missing various sections from the memory definition that we need. You seem to have removed the VECTOR and RESETDATA sections. The code will not operate correctly (in particular there is no place to hold crash data, which is essential to be able to identify what has gone wrong if the firmware resets). Removing those sections may have save 32Kb but I do not think it is a good idea. The current development version of the file looks like this: / Specify the memory areas / MEMORY { VECTOR (rx) : ORIGIN = 0x8008000, LENGTH = 16K RESETDATA (rx) : ORIGIN = 0x800C000, LENGTH = 16K FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 1024K - 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K } See: https://github.com/gloomyandy/CoreN2G/blob/v3.3-dev/src/STM32F4/variants/STM32F407/ldscript.ld

The older 2.2.2 version is here: https://github.com/gloomyandy/CoreSTM32F4/blob/v3.02-dev-unified/variants/BIGTREE_SKR_PRO_1v1/ldscript.ld

What file have you based your version on?

I really don't think it is a good idea to try and squeeze the firmware into this small memory size. There are plenty of boards out there that have sufficient memory to run RRF and that will also be able to support future versions. Although it may be possible to use a chip with a smaller memory, I think it is just creating a problem for the future.

[dream111119]

@gloomyandy I added MEMORY { VECTOR (rx) : ORIGIN = 0x8008000, LENGTH = 16K RESETDATA (rx) : ORIGIN = 0x800C000, LENGTH = 16K FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 1024K - 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K

The size of the compiled firmware is still 447K, and the function is currently being tested, I hope it can be effective

[dream111119]

@gloomyandy I am not using an old version of the firmware，I still hope that there is a correct process for adding chips to avoid confusion in the source code caused by more developers in the future. Thank you very much

[gloomyandy]

I'm confused in an earlier post you said the size of the firmware was 477K not 447K? Have you checked the map file that is produced to ensure that the highest address does not exceed the 512K of flash that the chip you are trying to use has? But even if the size is 477K I still do not see how that is possible unless you have made other changes to either the source or the build process. As this is smaller than any of the standard release builds that include WiFi functionality have been for some time. Which branch are you using as the basis for your work? If you have a working USB connection then can you post the output from M122.

Can you provide a link to your github repository and the branch you are actually compiling? Can you also provide details of the command you are using to compile the source with?

Can you provide more details of the motivation behind the port you are working on? Is this a private project or is this work for a board manufacturer? If you do not want to provide details publicly feel free to contact me via PM.

I'd also note that in the upcoming releases of V3.3 I have moved some of the larger objects into CCMRAM to make more standard memory available for other purposes and to improve performance. This memory is not available on the STM32F446VE.