When I run this code on my STM32L1 board, 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. Is there's any special configuration for float ?
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++){ } } } . . . volatile int timespan = 0; // Total pulse width int main(void){ float Distance; // actual distance in cm . . . while(1){ TIM4_Echo_Read(); Distance = (timespan / 58.0); if (Distance <= 100){ GPIOB->BSRRL = (1<<7); } else { GPIOB->BSRRH = (1<<7); } Delay(10); }
timespan is declared as a global int. Note that none of this happens when I declare Distance as int instead of float.
Any idea why the debugger keeps getting stuck on float instructions?
Is it stuck in the Hard Fault Handler? If you hit stop where is it stuck?
STM32L1 has no FP hardware, so you'd need to be using software emulation.
Are you?
If the target cpu is correctly chosen it should be using software libraries, and not permitting the FPU to be selected. If FPU code existed it would likely fault much earlier than this.
Check other things like the firmware and drivers for your debug pod, not sure that is the issue, but you should be able to stop the debugger and see exactly where it is stuck, and not require a reset or power cycle.
Do I have to define it or mention the float library at the start of the code? As of now I'm only including: #include <stdio.h> #include "stm32l1xx.h"
If yes, any idea what is the float software library for STM32Lxx?
@Andrew Neil Would you be kind and explain or share a useful link on how to use software emulation, I would be thankful.
As @Westonsupermare Pier said, If the target cpu is correctly chosen it should be OK.
Please answer the questions he asked.
What, exactly, do you mean by, "debugger hangs" ?
Where, exactly, does it "hang" ?
What I mean by "debugger hangs" is that when I run code on the debugger, and move step by step, once I try to steps over the line Distance = (timespan /58.0); everything stops, the icons that are supposed to run the code lines one by one can no longer be presses , the only option I have is either to stop (by pressing the red icon) or reset. And if I don't press anything, it can stay as it is forever, only the seconds counter will keep counting how long did the instruction execution took. and the only way to run the code again is by shutting off the debugger and open it again. because I tried running the code after stopping and reseting, but it doesn't run the debugger on the main.c anymore idk why. So I just turn off the debugger and run it again trying to figure out why this is happening. I hope my explanation is clear.
>> the only option I have is either to stop (by pressing the red icon) or reset.
And the question asked was WHERE does it STOP. The details and specifics are important to understand what has happened.
Make sure the stack is sufficiently large, and that the flash has the correct number of wait states for the speed your are running.
I checked the Start Up file and I found the stack size as following:
Stack_Size EQU 0x00000400
The STM32L1 has 256K RAM. Note that I'm using Timer interrupts, float, and delay in this code. I don't know how to calculate the recommended stack size. what are the criteria of doing so, and what would be the suitable size for this code. I hope I'm not asking for too much..
You not answering the questions is the problem I have.
The code looks reasonable enough, pretty sure I could paste it into a project and have it work out of the box. I lack sufficient and specific detail in your case to know where/why it stopped or crashed.
Make an effective presentation of what's happening, less narrative, more illustration.
I mentioned where and how, but maybe I misunderstood the question. here's a screenshot that should clear it.
http://imgur.com/a/3qDtE
You were asked to STOP to the debugger, and see where it was then. This is NOT what is portrayed in the image.
You've said where the tracing finished, not where it STOP, or where it was actually stuck. It tries to do the division, and doesn't return, the task in debugging this is to understand where it actually goes and becomes stuck.
You could also go into the disassembly view an STEP INTO rather than STEP OVER.
You screenshot shows that the stackpointer points to 0x20000658. Start the program and stop at main() and look at the SP value. If the difference is close to 0x400 you know the stack might be too small and the problem is a stack overflow. For a test set stacksize to 0x800 in the startup file.
@Westonsupermare Pier
I'm really trying to understand what you're asking me to do here. please consider me as a beginner and give me a clear troubleshooting steps, I would be thankful. I appreciate your support
@Gunnar Bohlen
When I first run the debugger, the first line it execute is the first line after the main(), which is the function SetHSI(). the SP value at that point is 0X20000670. So I increased the Stack to 0x00000800 and the SP value shows 0X20000A60 when executing the Distance line. Similarly, when I increased the stack to 0x000001000, the SP value showed 0X200001260 when executing the Distance line. Not sure what's happening to be honest.
I'll share the complete code in my next post, so you will know what I'm talking about. The code is supposed to calculate the distance by interfacing an ultrasonic sensor, and turn ON a LED if an object closer than 100cm is detected.