0

Using gcc-arm-none-eabi-5_42016q3-20160926 tool chain in eclipse. Processor: STM32F030 I have a 3 line program that starts before any hardware initializations to isolate the problem:

    int a;
    char * num="3";
    memset(0x20000970,0XAA, 0x20001f00-0x20000970);
    sscanf(num, "%i",&a);

I have set the RAM to 0XAA so I can see what gets clobbered, leaving plenty of room for the stack. After the memset instruction the stack pointer is at 0X20001F78, the memory is 0XAA up to 0X20001F00 as expected. After I execute the sscanf function the stack pointer is back at 0X20001F78 however memory was clobbered all the way down to 0X20001BB4 which makes me think that either this simple call took almost 1K of stack or there is some other error in the routine. I have stopped using this function but am curious whether this is expected behavior? Also, is there a list of C functions that one should avoid in embedded systems, this was a surprise to me but from searching I see I am not alone.

  • It might look like a "simple call" but the `scanf` family is complicated, and expensive. It has no idea what is going to be passed to it, and is effectively an interpreter. So `scanf` and `printf` sometimes have to be specifically enabled for embedded work (math library too). Your usage could be effected with `atoi`. – Weather Vane May 22 '20 at 12:51
  • Thank you, although I don't use printf in my embedded projects I have been using sprintf. I ran a similar test to the one above on sprintf and found similar behavior - memory was clobbered well beyond expected stack usage. I will go through my current products that may not be exhibiting a problem and pull these functions in the next release. This then leaves the question, what other functions should I look at to make sure they are not stack pigs? – DWSUSA05222020 May 22 '20 at 21:04
  • Are your short of code space and stack? Or is that a silly question for embedded code? In my day, it was as much about execution speed too. – Weather Vane May 22 '20 at 21:07

0 Answers0