|
January 28, 2009 - 1:25am
Guest |
Hello.
Has anybody encountered message 'No more break points available' when doing C-debugging ?
I actually had only 2 breakpoints and saw this message while doing step by step debugging.
Another message was shown afterwards: "The C step can only be performed using assembler steps because there are not enough available breakpoings. Do you wish to do it ?" I pressed 'Yes' cursor went to the next line but 'step over', 'step in' buttons remained disabled.
What does this message actually mean and how to workaround this situation ?
Ride7 is latest (7.14), debugger is RLink-pro, board is Reva. MCU is STM32F103RBT6
Thanks in advance
Andrew
|
Hi,
For C-stepping, Ride analyzes the code that is about to be executed and places one or two or more breakpoints on the next possible C lines of code. (or indirect jumps in case of switches or function calls) Then it launches the execution, waits until it reaches one of the breakpoints and removes them.
In case of the STM32, you only have six breakpoints available. That's how the chip is designed. This means that if you already use them as 'standard breakpoints', then Ride is not able to use them for stepping. When it sees this, it proposes you to either not do the step (so that you can remove your breaks and retry) or perform the C step by single-stepping in assembler until it reaches a C line. (But this second option can take a very long time if stepping over a function, for example.) This is the message that you see.
Now, if you only had two breakpoints and you received this message, this is strange indeed. And the step buttons being grey out is unexpected also. Were you stepping on a very complex C line? (switch, several 'if's, ...) Are you sure there were only two breakpoints set? (you can check that by clicking 'View'->'Debug Windows'->'View Flags') Can you send an example project to us that shows the problem? (support@raisonance.com)
Best Regards,
Vincent
Hello Vincent.
Thanks, as usual very interesting and instructive reply. It is helpfull to know that there are only 6 breakpoints possible.
I was not actually sure abot number of break points. Probably they were three. The line where debugger stumbled was quite complex - it was actually a cycle written in one line. I was able to work around the problem by rewriting this line.
Today I will try to reproduce the situation and attach the code.
Thanks a lot.
Andrew