1

I successfully cross-compiled the GNU Scientific Library for my STM32F303 with an Arm Cortex M4, as I've described here:

How to crosscompile GSL for Arm Cortex M4?

However, this works fine, but now I got for every memory allocation from the GSL an HardFault. For example, this line:

gsl_vector_float *x = gsl_vector_float_alloc(2);

or this

T = gsl_multimin_fdfminimizer_conjugate_fr;

causes directly an HardFault. Has anyone an idea what the reason could be? I am pretty sure to have enough RAM (the IDE shows 59 kB free RAM at beginning). The problem holds only for GSL allocations, malloc stand-alone works perfectly.

Furthermore, I found on the internet some post that described thread-safety in the sense of using locks for malloc as a possible issue. Since the GSL is Thread-Safe, could this be the reason? Although I did not find any clue for using locks in the source code.

bilaljo
  • 358
  • 1
  • 6
  • 13
  • Use the debugger. – 0___________ Feb 07 '22 at 10:35
  • I already used the debugger (I even cross compiled GSL with -g3 -ggdb). It shows only that the fault occurs during allocation. – bilaljo Feb 07 '22 at 10:53
  • so debug it deeper. Enter the function and see **what** exactly is causing the fault. But I am quite sure that you do not have the correct **linker script** and you try to access non-existing memory. Adding some compile options if you compile for other uC is **not enough**. You need to have correct *linker script* and *startup files* – 0___________ Feb 07 '22 at 10:57
  • Thank you, I think the point with the linker script should it.Do you mean for cross-compiling or for µC? I am using the auto-generated of CubeID for the µC. – bilaljo Feb 07 '22 at 10:59

1 Answers1

0

As in the comments described, I've used indeed the wrong linker script during cross-compiling (the default linker script). It worked after specifying the linker-script (I had to use the linker-script for the specific MCU).

bilaljo
  • 358
  • 1
  • 6
  • 13