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-02 03:13 PM
If execution order is confusing try turning off optimization, one C line may take multiple assembler lines, and those may be rearranged.
2017-11-02 03:13 PM
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
2017-11-02 04:52 PM
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.
2017-11-02 05:02 PM
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.
2017-11-02 05:23 PM
Thank you. Setting 'Optimization' to Level 0 seems to be working at the moment. But I am having a bit of doubt as to the stability of the 'free' version.
I've been using this same 'free' version before for I2C stuffs but never had this problem before. I am not sure why I would have this problem now.
Thanks.
2017-11-02 05:32 PM
I don't think the free version is materially different from stock. The CM0 is however a significantly weaker core, with stripped down features including the ITM/DWT
2017-11-02 05:34 PM
Well I guess I am not trying to do any thing fancy but just some basic debugging can't seem to work. Now I am having another strange problem. At start up of debugging, it stucks in a endless loops. Now it won't go to main().
ApplicationStart
LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP2017-11-02 05:42 PM
Check what you are doing in SystemInit() likely in system_stm32l0xx.c. Look for loops waiting for clock sources, or PLL, etc.
__main is Keil's runtime initialization code that copies or zeros the statics in RAM before calling your main() function.
2017-11-03 04:13 AM
for some reason, that got stuck in moderation for over 12 hours!
:(