Problem with generated code

[Steven Burck]

Posted on March 01, 2015 at 07:52

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-hardfault

[Tesla DeLorean]

Posted on March 01, 2015 at 14:33

Does it fail if you compile with optimization turned off?

[vrouesnel]

Posted on March 02, 2015 at 03:02

What project did you use to convert to CrossWorks? Double-check your linker script and startup script.

[Steven Burck]

Posted on March 02, 2015 at 06:22

Yes, optimization is turned off in the debug version.

[Steven Burck]

Posted on March 02, 2015 at 06:24

Rowley 3.3.1 imports MDK projects directly.  I'm looking at the script for problems, so far haven't found any.

 

From: pinkman

Posted: Monday, March 02, 2015 3:02 AM

Subject: Problem with generated code

What project did you use to convert to CrossWorks? Double-check your linker script and startup script.

[Steven Burck]

Posted on March 02, 2015 at 09:32

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? 

[AvaTar]

Posted on March 02, 2015 at 12:48

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.

[Steven Burck]

Posted on March 02, 2015 at 15:02

No, actually Rowley support helped me solve the problem - as it turns out, I had to do the opposite of what clive1 recommended - raise the optimization level.  What happened:

the code of the cube generated function  HAL_RCC_OscConfig was full of asserts.  As Michael from Rowley explained to me, ''I think it's the use of assert - the compiler is creating localvariables to implement the asserts when built without optimisation. Bothgcc and clang do this. Set the optimisation level to to level 1 in thedebug configuration''

I had no idea.  Did it, and the program is running smoothly.  I still increased the stack size, but I expect they take the original stack size from the MDK project which was generated by STM32Cube, not just a default (it was 256 bytes, if I remember correctly).

[AvaTar]

Posted on March 02, 2015 at 15:21

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.

[Tesla DeLorean]

Posted on March 02, 2015 at 17:16

I had to do the opposite of what clive1 recommended

I asked a question.