Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Hardware fault, stuck in infinite loop at Default_Handler before reaching main() on STM32F3348-DISCO

I’m using a Discovery board for the STM32F334, called the STM32F3348-DISCOQuestion which has a STM32F334c8t6. Using CubeMX to generate a project, the project for EWARM runs ok but the project for SW4STM32 (OpenStm32) will fault before main() is reached. It faults at the first push to the stack. By default the stack is located at 0x20004000 as determined by the STM32F334C8Tx_FLASH.ld file generated by CubeMX for an SW4STM32 project. If I change this .ld file for a 12k rather than 16kB RAM size (i.e., locate the stack to 0x20003000), the program runs without faulting. The SRAM size specs (http://www.st.com/web/en/resource/technical/document/datasheet/DM00097745.pdfQuestion) are a little mis-leading - there is 16k of RAM but it’s not contiguous. The 12k portion is at 0x20000000 and the 4k ‘CCM RAM’ is at 0x10000000.

The work-around I found is to modify the .ld file with 2 changes:

  • change RAM size from 16k to 12k and,
  • more importantly, change the stack location from 0x20004000 to 0x20003000.

CubeMX will over-write these changes the next time the project is regenerated, so watch for that. Also, the makefile generated by CubeMX for OpenStm32 will not automatically re-build if the .ld file is changed so it’ll be necessary to force a rebuild (e.g. ‘clean’, or touch a .c file etc).

This was reported as a CubeMX bug on st.com hereQuestion.