Why is any debug attempt on the STMF3348 discovery board always ending up in the hardware fault handler?

[Clem1]

I am new to STM32 development and I have INCREDIBLE difficulties getting any example to run on any platform. I used to be able to run some very simple examples and even successfully implement changes on a TouchGFX-generated project, but changing the .ioc file was discouraged and quickly messed up things. More recently I have never managed to debug anything on the STMF3348 discovery board, let alone implement a DAC output (triggered from the timer and fed from DMA). If I am lucky if I reach the clock setup before falling over. Now, I have installed a cube F3 patch but none of the examples are visible, probably due to their different format (none was made for STM32CubeIDE but for SW4STM32 instead) and they do not show up in the MX tool. Anyhow, copying over the  SystemClock_Config() did not help as the system fell over evern before the HAL_INIT() ?! There must be a problem with the hardware setup but the board selection should take care of that. Is that board somehow obsolete? Could it be the debug settings? (Connect under reset?). I have previously developed using ATMEL (Atmel Studio, Visual Code with Platform IO), and Analog Devices / TI (using IAR) and never experienced such issues.

[Tesla DeLorean]

Perhaps build some of the CubeF3 / HAL examples using IAR should be project files for that.

​

Yes F3 rather old at this point. With other MCU experience I'd suggest root causing the Hard Fault

[Clem1]

Yes, the example code seems to work with IAR, thank you very much for the suggestion! Now, there is something very interesting going on as it was mentioned in a comment some crucial processor clock settings are in an .s file, and that these are set up before even reaching the main() entry point (see highlighted text). Is for the STM32CubeIDE the .ioc file equivalent to the .s file here, and could my failure to debug any code have originated in an incorrect .ioc setup? There were only some warnings, but none of the clock settings were red. I thought that the .ioc file is only creating a text substitution, updating the init function with the correct commands.I appreciate any explanation / link, as that seems to be the root cause of all my troubles with the CubeIDE.

[Tesla DeLorean]

The startup.s file typically contains the vector table, and enough assembler code to get the C Runtime working. In the CMSIS implementation you typically call SystemInit() to get the MCU and external memories functioning to the point where C statics and C++ constructors can be initialized, before calling main()

On IAR some of this is done via __iar_program_start

 THUMB
 PUBWEAK Reset_Handler
 SECTION .text:CODE:NOROOT:REORDER(2)
Reset_Handler
 LDR R0, =SystemInit
 BLX R0
 LDR R0, =__iar_program_start
 BX R0

SystemInit() typically lives in system_stm32f3xx.c or similar file. Often get the FPU started, clocks/PLLs, and points the Vector Table into SCB->VTOR register.

[Clem1]

Doesn't that type of information normally go into a .ld linker script, for example defining the entry point address and where certain memory sections sit? From a practical viewpoint, say that one does not have to write the .s file manually (which I sincerely hope!), is there a proven workflow to setup a EWARM STM32 project (HAL/CMSIS for DSP) from scratch for any STM processor on any board, such as STMCube -> GUI selection of processor, clocks and ports -> .s file -> compiler/linker settings in IAR?

[Tesla DeLorean]

The MCU runs code not linker scripts.

Th​e linker script tells the Linker how the memory is arranged so it can build a suitable image.

ST provides sample startup files for the major tools chains. The GNU/GCC one working for CubeIDE, Atollic, SW4STM32, etc.

There are project templates too. For IAR and KEIL​ should be able to clone or dupe those.

[Clem1]

Thank you for the tip and I will have a look into the literature at some point. But I do think that most of the issues that I am having are around some setup/debug problems. Let us forget about other IDEs for a moment and go back to STM32CubeIDE. I have run an example targeted for the STM323H747I-EVAL board on the Arduino Giga R1, which has the same processor. I get that the clock setup may be different, but I managed to compile, download and debug up to CPU_CACHE_Enable(), at which point (when calling SCB_EnableDCache();)I got an error. Then I selected the "halt all cores" option. It seems that the M7 core starts up first (probably at a generic slow clock?) and both MCUs need to be halted for that to succeed (or something along this line, excuse my vague expression). Right, that one did the trick and I managed to successfully run CPU_CACHE_Enable(). But I tripped over the point where CPU1 (M7) waits for CPU2 (M4) to boot and enter into stop mode, but it timed out. So there must be a problem with the fact that the Arduino board is somewhat different (maybe a different crystal/clock source), but have in mind that this happened before HAL_init() and SystemClock_config() were called, so the clock setup is not likely to blame. I am missing a link, maybe some action/setting which needs to be performed before being able to run the STM32H747 (or any other processor) on a different board? Note that the .ioc file was missing from this project. My goal is to set up a simple project with simple code that runs on the STM32H747 but on any chosen platform. I really want to understand in detail what is going on "behind the scene" in the mentioned debug session, so your insights are highly appreciated.