STM32F103 migration to STM32F215 and .ld script

[neoirto]

Posted on October 18, 2014 at 14:03

Hi all,

I need to prepare a migration from existing fully functional code on STM32F103 (custom low level drivers, relatively complex interrupts and DMA schem, USB MSC with FatFS to drive uSD card : Nemuisan version) to STM32F215 architecture. I already verified the DMA changes won't affect functionality in theory. I plan to use EMBLOCKS gcc to build new STM32F215 version (I was using CoIDE for STM32f103, but this IDE does not support F2). So I understand from

http://www.st.com/web/en/resource/technical/document/application_note/DM00033pdf

the migration won't be too difficult by just switching Std_Periph_Lib and updating low level drivers, especially DMA schem. Code will probably be highly portable, do you confirm ? Do you have any experience advises regarding that migration ? But with the Cube support of the F2 architecture (especially concerning USB MSC + FatFs) by doing this simple code migration, I will loose all the perf upgrades done on Cube ? How much faster the new MSC is compared to last STM32 USB driver please ? What would you do in stead of me ? About the needed .ld script : can I use the stm32_flash.ld of the STM322xG_EVAL and just change with appropriate f215RE values in the first part of the file :

/* Highest address of the user mode stack */
_estack = 0x20020000; /* end of 128K SRAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0; /* required amount of heap */
_Min_Stack_Size = 0x200; /* required amount of stack */
/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}

Thank you in advance for your help ! #stm32f2-linker-script-.ld

[neoirto]

Posted on October 27, 2014 at 18:11

Do you remember if it was a lot of work to clean the ST example code to get a clean library for F2 ?

When you say it works on Windows, do you mean it does not on Mac or Linux ?Tx again ;)[EDIT]: I have to clean all the ST USR (User Application Layer) and LCD related, then it will be ok ?

[Tesla DeLorean]

Posted on October 27, 2014 at 19:10

Means I only tried it on Windows, and it handles Microsoft's dysfunction adequately.Yes, stripped out LCD stuff, and any board specific stuff, the SDIO interface uses the same pins, the Card Detect GPIO was adapted. I also fixed some >2GB dysfunction on ST's side.

https://community.st.com/0D50X00009XkZKMSA3

 

https://community.st.com/0D50X00009Xka2WSAR

 Edit: Fixed DEADLINKs, original post from 27-October-2014

[neoirto]

Posted on October 27, 2014 at 23:38

Thanks a lot Clive.

I am working to adapt your STM32F4 code for STM32F2:

https://drive.google.com/file/d/0B7OY5pub_GfIRUJPSUVxNTV3TEk/edit

After a first read, I understand it will be very similar : same GPIOs, DMA stream / channel are the same too on F2 and F4.So I have to modify (adjust GPIO config if necessary and clock related values) in : stm32f4_discovery.hstm32f4_discovery.cstm32f4_discovery_sdio_sd.hstm32f4_discovery_sdio_sd.cusb_bsp.cAnd for example define :USE_USB_OTG_FSAnd it may work as expected ?About the GPIO config in USB_OTG_BSP_Init():I just routed the D+ and D- pins on the F2 (PA11 + PA12). Is it compatible with your code ?What are PA8 (FS SOF) related ?USB_OTG_FS_SOF_OUTPUT_ENABLED is disabled by default so it won't be a problem is that true ?

[Tesla DeLorean]

Posted on October 28, 2014 at 03:19

You should be able to pull the clock stuff via your system_stm32f2xx.c, and vectors via startup_stm32f2xx.s

Check the makefile for definitions passed to the compiler. Pretty sure SOF/PA8 aren't utilized here, and the other USB and SDIO pins are the same. As mentioned the GPIO used for the card detect can be any free pin and the thing that's usually different from board to board.

[neoirto]

Posted on October 28, 2014 at 12:15

Ok

In my config (device FS), I have no PA10 used for ID pin too... So is this pin software controled ? What do you think about the following function please ?

* @brief USB_OTG_SetCurrentMode : Set ID line

D+ line is just pull up with an external 1.5K pull up to detect device connected on the bus : when do you think I should pull it up after initialization step ? May I modifiy something else (of course it compiles successfully now) ?