2017-11-02 02:28 PM
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.2017-11-03 07:29 AM
Infuriating isn't it?
2017-11-03 09:08 AM
Obviously, that was a sample codes used for illustration. I feel like you were joking.
2017-11-03 09:24 AM
Well, as noted, it was obvious that it wasn't the real code - but it was not obvious what it was supposed to be!
But it's all a bit late now - after the moderation delay.
2017-11-03 10:25 AM
Well you did complain about stuff not working and then post code that was of no real help in understanding the problem.
ie 'this is my specific problem' with code that's not entirely exculpatory or specific ..
2017-11-03 10:31 AM
Is it just me or is there a bunch of this thread that's not visible from the 'thread view'? Did someone delete posts, or are they in moderation, or under something in moderation?
Kling.Brian
2017-11-03 10:31 AM
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.
2017-11-03 10:38 AM
My first reply still says that it's 'in moderation' - despite that fact that it is (was?) visible this morning, and I received the notification saying it was appoved...
2017-11-03 10:48 AM
I saw it, did it get edited? I can just see these posts on my Welcome Page
2017-11-03 10:56 AM
I can still see it
2017-11-03 11:38 AM
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.