2015-08-04 12:40 AM
So many of you know i am having hard time to make my STM32F4 program work with STM32F7 micro.
Latest finding for me looks just not acceptable. So many people to make programs shorted use function calls inside IF statement like this:if(read_spi(0)==222)
{
//todo
}
So my uint16_t read_spi(uint16_t address) function simply was returning camera id based on register so i could upload register for proper operation. It does not matter what read_spi returned, it always get into //todo statement !!!!!!!
So if i make this function a bit more to hardware by first reading id to register, and using register RX for if statement, it does work as it should. This is to be expected.
uint16_t reg = 0;
reg = read_spi(0);
if(reg ==222)
{
//todo
}
So in general, it just does not like function calls, as example if(fabsf(-0f)==0f) does give answer YES. So question, this is normal, that each time i have to supply compiler with correct program flow, or it is just bug ?
2015-08-04 08:33 AM
As described it sounds like a bug, check optimization levels, and talk to your IAR support representative.
Make sure you don't have an errant semi-colon on the end of the 'if' line.2015-08-04 11:34 AM
This is short video that is a bit more basic;
https://www.youtube.com/watch?v=kGRyjc-o9cs2015-08-04 11:51 AM
Ok, if I follow what you're doing, then turning optimization off causes it to ignore the braced code. It's hard to follow what's going on in different panes.
Are you sure the optimized version is actually executing the function? Does the disassembly view provide more granularity on this? Optimized code can be non-linear, and the line-to-address in the C view can be a bit ambiguous, at least that's my experience with Keil and Microsoft tools. ie it might load constants into registers, but these don't get stored if the branch is not taken.Switch to the assembler pane, and step that one instruction at a time, or look at and critically analyze the created code.2015-08-04 11:59 AM
It is not executed.
Original code was made, so two different cameras will work with same code. Basically just call different camera register init function based on id. I was unable to make it work (camera was dead, no reason why), so i start to searching step by step, since with other camera it works (since if part was used for one camera, and else for other.) And when i split single if else function to two only if functions, no registers was initialized. this is how i spotted this problem, code was not executed. strange, but with highest optimization , calling to GPIOA->IDR and doing logical operations will work just fine. ( shifting and anding bits for checking single pin's) Also, i did checked if spi returns correct number, nad yes, it did ( basicaly i steped in spi function and checked return value, it was correct, but if(1==2) was true condition2015-08-04 12:34 PM
Corrupt register can be an issue, either intrinsically from the code generated, or the call tree overflowing the stack, or stack based overflows/corruption at an array/variable level. Things not be recognized as volatile properly is another.
If you have a clear and demonstrable issue, you need to share it with IAR technical staff, venting here will not get resolution. You'll have to get beyond the front-line support, because just about everyone claims to be the victim of a ''compiler bug''.I'm just saying that debugging information within objects doesn't work well with optimization because the line-to-line associations are course and ambiguous at best, and deceptive at there worst. One line of C code can create half-a-dozen or more assembler instructions, and code can be interleaved with other lines of code.2015-08-05 02:05 AM
This problem does not show up with STM32F4 using same code, and same optimization level, clock speed, and so on. only difference i am using SLP libraries on F4, HAL on F7, and of course different cores M7 versus M4