Hi Alan,

I recently created a port for the STM32F7xx, which is not complete due
to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is
waiting to be merged:

https://github.com/apache/incubator-mynewt-core/pull/179/

And I used as base for the startup/etc files STM32Cube V1.6.0. My idea
would be to upgrade all STM32Fx ports to that version, to at least have
some tracking of what versions are being used, etc, otherwise everything
is getting to be messy with lots of different ext files around.

Anyway, at least two changes I remember having to do to the startup_*.s:

1) It jumps to "main" at the end of the Reset_Handler. You need to
change it to jump to "_start".
2) There is already zeroing of the "bss" section, but you also need to
add zeroing of "corebss".

Of course the linker script also has to be updated accordingly
(sections/labels that match).

Cheers,
Fabio Utzig

On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> I've been working on what I thought was a simple port to this
> architecture and have a problem with versions for the startup files. If I
> understand the STM architecture directories correctly I was expecting to
> simply swap out files used by the 'stm32f4discovery' package (ie. V1.4,
> dated 09-Jul-2012):
>    hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> with this one needed by my port:
>    startup_stm32f427xx.s
> 
> Unfortunately I found that the external CMSIS files located in this
> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>    
> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f407xx.s
> 
> Naturally I assumed that this would be a straight forward port since the
> microprocessor are very similar. Does anyone have the right version of
> the startup file that I can use?
> 
> Note that from what I can tell the include files being used by
> 'stm32f4discovery' port are being mixed with an older startup file
> version. Even though this appears to be working, I would suggest that the
> current STM bsp be brought up to date to use the newest CMSIS support as
> the global variables are quite a bit different. This would save others
> from running into similar confusion and porting problems.
> 
> ALan

Reply via email to