Skip to main content
mengsk8086
mengsk8086
Associate
September 19, 2015
Question

STM32CubeF7 bug report

  • September 19, 2015
  • 5 replies
  • 1614 views
Posted on September 19, 2015 at 23:35

Hi,

The function SystemInit_ExtMemCtl() in the file system_stm32f7xx.c is not ported to STM32F7-DISCO, since the DISCO and EVAL use different SDRAM, it will not work.

Another thing, the SystemClock is configured in the main(), it should be in the SystemInit() like other families(no matter F1-F4) to ensure the speed of C++ initialisation, especially the compiler is configured to put data in ExtSDRAM.

In conclusion, the file 

system_stm32f7xx.c should be updated :

different ExtMemCtl for DISCO and EVAL

add 

SystemClock config

add QSPI MemMapping 

initialisation

    This topic has been closed for replies.

    5 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    September 19, 2015
    Posted on September 20, 2015 at 01:09

    Another thing, the SystemClock is configured in the main(), it should be in the SystemInit() like..

    I totally agree, all this pre-init stuff needs to get done early and properly so the C Runtime code can clear and copy the statics properly, and optimally. This is what CMSIS expected, so why this has been regressed is beyond me. I had to fix the SDRAM init code on the STM32F429I-DISCO too, so I'm not sure if someone there doesn't understand the purpose of getting the clocks, and external memories fired up in SystemInit(). Can we get a senior SW guy at ST to look this stuff over critically? Thanks.

    I'd +1 the post, but can't do that for the top post.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Nickname5522_O
    Nickname5522_O
    Visitor II
    September 21, 2015
    Posted on September 21, 2015 at 19:51

    Hi guys,

    Discussed issues were reported with high priority to development team. 

    Thank you for your strong contribution :)

    -Shahrzad- 
    Nickname5522_O
    Nickname5522_O
    Visitor II
    September 22, 2015
    Posted on September 22, 2015 at 10:27

    Hi,

    Development team confirmed that next STM32CubeF7 v1.2.0 will contain a system_stm32f7xx.c that configures the SDRAM of Discovery.

    Have a nice day :)

    -shahrzad-

    Tesla DeLorean
    Tesla DeLorean
    Guru
    September 22, 2015
    Posted on September 22, 2015 at 22:47

    Sorry, it's just a little frustrating, the code is going to end up in thousands of devices, you have to be more careful, the Microsoft method of fixing some things, breaking others, with perpetual software releases doesn't work well in embedded.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Raouf Hosni
    Raouf Hosni
    ST Employee
    October 14, 2015
    Posted on October 14, 2015 at 03:19

    Hello,

    Let me provide some clarifications and how things will be improved.

    We are receiving more and more requests about system_stm32xxx.c file provided within STM32Cube, mainly people are looking to have register access based code for the initialization of

    1) system clock at the highest frequency

    2) QSPI memory available on ST board

    point 1) Was implemented in legacy SPL then removed in the STM32Cube, based on customers feedback who don't want to have the system clock already configured when reaching the main(). As tradeoff, we will provide code for system clock config (based on direct registers access) that will be enabled through compilation switch (disabled by default, up to user to enable it).

    for point 2) Generally  pre-init configuration is needed to initialize external (SRAM/SDRAM) memory to be used as program data  (for heap/stack as example) as extension of the internal SRAM. This is the purpose of CMSIS SystemInit_ExtMemCtl() function.

    Of course this could not be the case for QSPI Flash, where it’s rather used for code execution.

    However we can extend the purpose of SystemInit_ExtMemCtl() function to provide a compact initialization of the QSPI, coupled w/ system configured at the highest frequency, to implement use case as execute in place. This will shorten the application overall startup time and improve performance.

    Updated example will be provided within next version of STM32Cube FW packages.

    From other side we are planning other changes to avoid some issues seen recently about the usage of the system_stm32xxx.c template file: this file is provided with implementation of SystemInit_ExtMemCtl() for one target board (usually EVAL board), which needs modification when running on another board.

    To resume, below how system_stem32xxxx.c file will be managed within STM32Cube FW

    o system_stm32xxxc.c template file provided within STM32 CMSIS drivers

        - system running at default clock configuration (typically HSI or MSI

        - SystemInit_ExtMemCtl() remains empty

    o system_stm32xxxc.c user file provided within FW examples: will provide custom file per board (within Projects\<board_name>\Templates) , where 

        

    - system running at max clock frequency, activated through compilation switch

       

    -  SystemInit_ExtMemCtl() remains empty if no external SDRAM/SRAM/QSPI available on board 

      

     -  SystemInit_ExtMemCtl() updated to configure external SDRAM/SRAM/QSPI available on board, activated through compilation switch

    Feel free to share your feedback.

    Jasmin.

    Sorry, it's just a little frustrating, the code is going to end up in thousands of devices, you have to be more careful, the Microsoft method of fixing some things, breaking others, with perpetual software releases doesn't work well in embedded.

    Terms & ConditionsAccessibility statement