2015-02-28 10:52 PM
I've just started a project using the STM32F103VF. I generated code using STM32CubeMX, and imported it into Rowley Crossworks (my toolkit). It converted, and loaded, but when I run the code, before I even get to my own user code, it gets a hard fault and dies. The fault occurs in HAL_RCC_OscConfig, when setting the local variable tickstart to 0. The assembler line str.w r3, [r7, &sharp0x3EC] causes the fault. r3 contains 0, and r7 contains 0x1ffffed8. Now, the address of tickstart is in fact 200002C4 (according to the debugger), and this is a legal SRAM address on the device, but is still causing a hard fault. Any ideas?
#stm32cube-stm32f103vf-hardfault2015-03-01 05:33 AM
Does it fail if you compile with optimization turned off?
2015-03-01 06:02 PM
What project did you use to convert to CrossWorks? Double-check your linker script and startup script.
2015-03-01 09:22 PM
Yes, optimization is turned off in the debug version.
2015-03-01 09:24 PM
From: pinkmanPosted: Monday, March 02, 2015 3:02 AMSubject: Problem with generated code
What project did you use to convert to CrossWorks? Double-check your linker script and startup script.
2015-03-02 12:32 AM
I've managed to circumvent the problem, but it leads me to another question, possibly for Rowley or possibly cube related. The stack defined was small, and for some reason, the stack frame which was generated was around 1000 bytes. As soon as it entnered a function with locals, sp became out of range (1ffffed8, in my case), and as soon as a local was touched it flew. Making the stack 10000 bytes solved the problem, although I can't see why such a huge stack frame was set up. I haven't gone over all the cube generated code, is there somewhere with a giant local allocation which propagates into every stack frame?
2015-03-02 03:48 AM
I haven't gone over all the cube generated code, is there somewhere with a giant local allocation which propagates into every stack frame?
Functions of the printf() family use to have a large stack footprint. Or, using the FPU both in main code and interrupts (i.e. saving FPU context) increases the stack frame. BTW, Crossworks is notorious for their tiny initial stack size. They still use to startup with 128 byte, which do not hold long. So setting a proper stack size is one of the first things I do after setting up a new project.
2015-03-02 06:02 AM
2015-03-02 06:21 AM
Interesting to hear.
I didn't yet ran into this problem, since I'm no Cube user (and not planning to do so). The 'old' StdLib code used asserts already quite generously.2015-03-02 08:16 AM
I had to do the opposite of what clive1 recommended
I asked a question.