Skip to main content
Vu.Andy
Associate III
November 2, 2017
Question

KEIL debug issues with STM32F030F4P6

  • November 2, 2017
  • 25 replies
  • 3670 views
Posted on November 02, 2017 at 22:28

I am having some debugging issues with Keil uVision5 eval (free) version. Now the STM32F030F4P6 has 16K bytes, and when I compile my program, it is approaching the memory limits. Below is the code size:

Program Size: Code=15524 RO-data=300 RW-data=540 ZI-data=2460

Here is my specific problem. I have two functions:

double GetSingleCellVolt(int cell);

void GetCellVoltArray(double *pa_volt)

{

call GetSingleCellVolt(int cell);

}

Now when I call GetCellVoltArray() by itself, then it always returns 0 regardless.

But if I call GetCellVoltArray() which calls GetSingleCellVolt(), then it works fine.

Now when I step inside the function GetSingleCellVolt(), to debug, the codes seem

to be executed in wrong order. For example, line 4 gets executed before line 3 ....

And there are variables inside GetSingleCellVolt() cannot be viewed because the

debugger complains that the variable is 'not in scope' but clearly the variables are

inside the function.

I don't know if this problem is specific to my case since my guess is my memory

limit is right up to the uC limit or it's something else.

Thanks.

Note: this post was migrated and contained many threaded conversations, some content may be missing.
    This topic has been closed for replies.

    25 replies

    Tesla DeLorean
    Guru
    November 2, 2017
    Posted on November 02, 2017 at 23:13

    If execution order is confusing try turning off optimization, one C line may take multiple assembler lines, and those may be rearranged.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Vu.Andy
    Vu.AndyAuthor
    Associate III
    November 2, 2017
    Posted on November 02, 2017 at 23:52

    Could you point out which 'optimization' should be turned off?  There is an optimization level 'Level 1 'O1', Level 2 ...

    I set 'Optimzation' to default but I am having the same issue where codes are executed not in order and some lines of codes are skipped.

    For example, these codes are used to read voltage using I2C:

        int val = 0;

        uint8_t b[4];

          int cellidx = ar_mainCellV_idx[(int)2];

        b[0] = (uint8_t)((0x0c + (cellidx)*2));

        ReadBuffer(G_BQ76930Addr, b, 2);

     

        val = b[0] << 8;

        val = val | b[1];

        double cell_volt =  (double)val * G_cell_volt_lsb;

       The debugger executes ReadBuffer(G_BQ76930Addr, b, 2) then b[0] = (uint8_t)((0x0c + (cellidx)*2))

       then it would skip the next three lines altogether.  I mean these are just basic codes so I am not sure

    what could be the problem.

    I am using the 'free' version so could it be the case?

    Thanks.

    Tesla DeLorean
    Guru
    November 3, 2017
    Posted on November 03, 2017 at 00:02

    Level 0 would be what you want.

    http://www.keil.com/support/man/docs/uv4/uv4_dg_adscc.htm

     

    You might also want to look at the assembler code generated and how that meshes with source.

    Sometimes it helps to print out intermediate values, and makes sure things proceed as expected and have appropriate values.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Andrew Neil
    Super User
    November 2, 2017
    Posted on November 02, 2017 at 23:13

    The code you posted doesn't make sense:

    double GetSingleCellVolt(int cell);
    void GetCellVoltArray(double *pa_volt)
    {
     call GetSingleCellVolt(int cell);
    }�?�?�?�?�?

    That wouldn't even compile!

    Please copy & past the actual code - and use the 'Syntax highlighter' to get properly spaced code layout - as above

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    Andrew Neil
    Super User
    November 3, 2017
    Posted on November 03, 2017 at 11:13

    for some reason, that got stuck in moderation for over 12 hours!

    :(

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    Tesla DeLorean
    Guru
    November 3, 2017
    Posted on November 03, 2017 at 14:29

    Infuriating isn't it?

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    S.Ma
    Principal
    November 3, 2017
    Posted on November 03, 2017 at 18:31

    Usually we try to avoid float and double whenever possible. It adds to the memory space the fload/double ansi library.

    If you can, try to use fractional bit type such as Q31 (16 bit integer, 16 bit fractional bits), or simply a multiplied value such as Voltage_mV or Voltage_uV or Voltage_V_x100000 (as long as it fits a signed 32 bit quantity).

    Make sure you don't use float or double within an interrupt. These variables are not saved in the stack automatically...

    Last, if you want to debug, you can create a volatile global variables and save your values in there for debug to watch them and modify them during breakpoint. Most local variables are put in registers or stack.

    Tesla DeLorean
    Guru
    November 3, 2017
    Posted on November 03, 2017 at 18:38

    Might want to explain that to the guys writing the HAL U(S)ART libraries, some float math in there that pulls in the whole library for free.

    Floating point on the CM0 is an entirely software endeavour, all the registers used will be stacked, and are completely thread and interrupt safe.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Andrew Neil
    Super User
    November 3, 2017
    Posted on November 03, 2017 at 18:44

    Ha Ha: that recently turned up on another manufacturer's forum - with a user shocked  at the amount of code his UART initialisation (using their 'HAL')  took!!

    :(

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.