# Debugger hangs when reaching to Float or Delay

When I run this code, the debugger hangs once it reaches to a Float (in this case the variable 'Distance') or Delay, I mean it seems like it's processing, however it never goes through, and I have to close it and run the debugger again, which hangs of course again. Note that the code builds without errors or warnings. The following is the related part of the code:

    void Delay(int x){
//input milliseconds, delay that number of milliseconds
int a,b;
for(a=0; a<x; a++){
for(b=0; b<1000; b++){
}
}
}

int main(void){

float Distance;     // actual distance in cm
.
.
.

while(1){

Distance = (timespan / 58.0);

if (Distance <= 100){

GPIOB->BSRRL = (1<<7);
}
else {
GPIOB->BSRRH = (1<<7);

}
Delay(10);
}


Any idea why?

• Get OUT of C and switch to assembly with your debugger. My guess (and it is nothing but a totally random guess from exactly 10 seconds reading this stuff here), is that a function is called that you cannot see in the C code but which would be abundantly obvious if you were in assembly. And that code is killing the debugger (by perhaps not returning.) If in assembly mode, you could step into that function and at least find out. (If you are uncomfortable with the assembly code generated by a C compiler, you really need to work on that. I don't think it's an optional skillset.) – jonk Aug 7 '17 at 19:24
• @lightworks You need to develop that skill. Use this as your motivation to move forward. I consider it unacceptable for an embedded C programmer (claiming the name) to be unable to hand-generate assembly code from C for a generalized target ALU. They must also understand what a function prologue and epilogue is, what an activation (frame) record is, and what purposes it serves and may optionally serve, and how compilers allocate registers, etc. They should be able to grab docs, very quickly navigate to the specific details of the specific compiler for a specific CPU, too. This is your moment! – jonk Aug 7 '17 at 19:37
• Interesting... If it always works when Distance is an int, then you may need to take jonk's advice and dig deeper. – DigitalNinja Aug 7 '17 at 19:40
• Is this a Cortex-M4F with floating point hardware? Are you using the floating point hardware or is it linking with a software library to perform the floating point calculations? Is the floating point hardware unit enabled? – kkrambo Aug 7 '17 at 20:33
• It would seem that STM32L4 is a Cortex M4 with FPU. The rest of the family members do not have a FPU. Using floating point variables on a MCU without FPU is always plain wrong and very bad engineering. It seems quite unlikely that you need them too... why are you using centimeter as an internal unit of your program? That too suggests bad design. Use a raw data type similar to the one used by your sensor and only scale to centimeter just before displaying the result to the user. – Lundin Aug 10 '17 at 11:56