Before logging an issue, please update to the latest release of Visual Micro from the Downloads Page.

When Logging a Support Issue in the Forum, please ensure you have also:-

  • Enabled vMicro > Compiler > Show Build Properties
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
  • Click the Reply button and attach as .txt file OR
  • Click here to Email us with the file attached, and a link to your post
Support requests without the output above may be impossible to answer, so please help us to help you
 
Page Index Toggle Pages: 1 Send TopicPrint
Hot Topic (More than 8 Replies) Strange behavior on Breakpoint (Read 2998 times)
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Strange behavior on Breakpoint
Jun 14th, 2021 at 1:59pm
Print Post  
Hi!

See attached 2 screen dumps, First hit is expected, but when I press "Continue" it hits the second Breakpoint (line37) immediately, I would expect to hit Breakpoint_line33 each byte update in the while loop, how come this behavior?

Thanks,
Anders
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #1 - Jun 14th, 2021 at 3:25pm
Print Post  
Thanks for the report.

We would expect it to stop on each iteration of the loop as described.

A few questions to help us understand further:
  • Does the watch expression data show that the loop needs to run multiple times?
  • If you put a simple Serial.print(p) into the loop does this output multiple times as expected?
  • Also with the Serial.print code present, does it iterate the loop correctly in the Hardware Debugger?
  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #2 - Jun 15th, 2021 at 6:59am
Print Post  
Yes it runs 0x15FC9 times, see attached es.png

Yes the code works OK after I press continue , the serial print works OK, it print the following to serial2:
Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:90057

See also attached Disassembly_view.png
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #3 - Jun 15th, 2021 at 7:20am
Print Post  
Another observation:

If I clear the serial2 terminal after I stopped the debug-session and starts the debug session I can see that it programs via the Atmel-ICE, but before hitting the first break-point in the loop, it seems to have run the program twice, from what I can see in the Serial2 terminal:
Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:90057
Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:90057

I have also attached the output from "Micro Build"
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #4 - Jun 15th, 2021 at 7:45am
Print Post  
Now I tested F10 (Step-over) at the first break-point and it works fine in the loop, so the first break-point is stopping correctly but the "Continue" is the problem, I will test with conditional hit, stopping after the 10th time for instance, now:

Conditional hit on break-point is not supported Sad
  
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #5 - Jun 15th, 2021 at 8:51am
Print Post  
Thanks for the detail.

If you add a Serial.print(".") to the inside of the loop is this all still the same?
(This may prevent the compiler unrolling the looped statements is the reason for this request)

It could also be that the loop has run by the time the debugger attaches, if you add a breakpoint above the while loop, does it land there, and then allow stepping through the loop?
Alternatively adding a delay(3000) at the top of loop can achieve the same aim if the load timing is an issue.

Conditional Breaks and Hit Counts are not supported in Hardware debugging, however are fully supported using the Serial Debugger.
  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #6 - Jun 16th, 2021 at 7:01am
Print Post  
Yes it has to do with the long time it takes for the "debugger to attach to target", when I add a dummy loop after my first stack-filling loop, then it works fine to stop each time in the dummy loop.

Is this slow attachment behavior caused by using the cheap Atmel-Ice, would it improve with a Segger J-link (plus, or even a Ultra+ version)?

I miss a reset button also, only way now to restart, is to close the debugg session and start again or?

It seems to to do 2 resets at the startup/attaching to target, I get this serial prints that comes after my first break-point,see below;
Would this also be improved with a better Hardware, like the the Segger J-link?

Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:100
dPosSetpo

Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:100
dPosSetpoint = -2147483639.06
dPosSetpoint = 2147483643.84
  
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #7 - Jun 16th, 2021 at 10:06am
Print Post  
Thanks for the detail, and it makes more sense its a timing issue now.

If you want to reset the chip when using "Debug > Attach To Process", you can add a Local board.txt to the project (vMicro > Add Code > Add Local board.txt), and put the below content in, and save it.
Code
Select All
# Force the Chip to Reset when Debug > Attach to Process is used for AtmelICE (vMicro)
vs-cmd.Debug.AttachtoProcess.tools.atmelICE.server.initCmd=-c "init; reset halt" 



This will run the reset command as part of the attach process as well as the debug > start.

I'm not sure at present if a different debugger will avoid this, and would have to check with other probes.  It could also be affected by the PC speed, and possibly the software stack being loaded (MI/OpenOCD/GDB), though if it was the software stack I would expect to see it on all boards.

The software modification to wait a second or two before continuing with the main code may be the safest way to work with this particular setup, and this could be wrapped in a #ifdef to ensure it only affects your Debug Builds, and not release builds.

Code
Select All
#ifdef _DEBUG
	while (millis() < 3000) {
		delay(100);
	}
#endif 

  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #8 - Jun 16th, 2021 at 10:25am
Print Post  
To reset in an ongoing debug session I still need to first press the red stop button and then green Continue, or can the "Local board.txt" be called in some way?
And what about the 2 resets before hitting the first break-point?
Will the 3000ms delay stop the 2 resets? how?
I will test the 3000ms delay after lunch
« Last Edit: Jun 16th, 2021 at 11:16am by Simon@Visual Micro »  
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #9 - Jun 16th, 2021 at 11:20am
Print Post  
With the board.txt change, the board will reset every time the Debug > Attach to Process is used (so you don't need to use Debug > Start Debugging, and do the build and upload every time you want to start at the start of the program).

I expect two resets should only happen when the Debug > Start is used, and will see if we are resetting at two different layers of the software.

The delay wont prevent the double reset, however if it is still waiting when the second reset occurs, the program essentially wouldn't have done anything yet, so should achieve the same thing from the perspective of watching the Serial output.
  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #10 - Jun 16th, 2021 at 11:36am
Print Post  
The delay actually is fixing the 2 resets, see attached 3000ms_delay_fixing_the_2_reset.png
Note the Empty COM9 terminal, where startup ok messaging was comming twice before?!

Regarding the break point behaviour:

First break point is line 46 as shown in the attached 3000ms_delay_fixing_the_2_reset.png
pressing green Continue => line 43 is hit with dummy-cnt =0x1e as before pressing continue
pressing continue again => line 50 is hit with dummy_cnt = 0x15fe7 (expected value after completed loop)

NOTE if I instead of continue, use F10 (step-over) at the first hit on line 46 i can step through all steps in the loop

Strange behavior? or?
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #11 - Jun 16th, 2021 at 11:40am
Print Post  
ok I read again and see your last sentence with the double reset explanation when having a delay before printing will "cover" the reset behavior
  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #12 - Jun 17th, 2021 at 1:02pm
Print Post  
Hi again,

Have you been able to reproduce and/or understand the strange difference between using continue and stepping with f10, as I described below:

Regarding the break point behaviour:

First break point is line 46 as shown in the attached 3000ms_delay_fixing_the_2_reset.png
pressing green Continue => line 43 is hit with dummy-cnt =0x1e as before pressing continue
pressing continue again => line 50 is hit with dummy_cnt = 0x15fe7 (expected value after completed loop)

NOTE if I instead of continue, use F10 (step-over) at the first hit on line 46 i can step through all steps in the loop
  
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #13 - Jun 17th, 2021 at 3:21pm
Print Post  
Thanks for the detail.

I have not been able to reproduce this at present on our setup, and continue iterates through the loop as expected on my test.

I'll try again shortly and update, and if possible could you send the whole project as a ZIP to us at sales@visualmicro.com, just so we have all of the same setup when testing.
  
Back to top
 
IP Logged
 
Anders Eriksson
Junior Member
**
Offline


Posts: 30
Location: Gothenburg, Sweden
Joined: May 31st, 2021
Re: Strange behavior on Breakpoint
Reply #14 - Jun 18th, 2021 at 6:10am
Print Post  
Hi,

I just sent the complete project as a zip file to sales@visualmicro.com
  
Back to top
 
IP Logged
 
Simon@Visual Micro
Administrator
*****
Offline


Posts: 2145
Joined: Feb 13th, 2019
Re: Strange behavior on Breakpoint
Reply #15 - Jun 18th, 2021 at 9:36am
Print Post  
Thanks for the project, and it seems this is due to how the compiler interprets the code to assembler.  I believe it has moved the looping construct to the ASM instruction level so it doesn't return from the ASM until the loop completes essentially, which matches the behaviour we see.

To land on the break within the loop each time the below solutions all seemed to work for me:
1) Move the Serial.begin(115200) above the loop (not sure why this alone worked but it did for me)
2) with #1 in place add a Serial.print(*p) to the inside of the loop (if #1 works alone then not really needed).
3) Force absolutely no optimization within setup() using the #pragma directives below (can remove #1 & #2 here):
Code
Select All
#pragma GCC push_options
#pragma GCC optimize ("O0")
void setup()
{
// Your Setup Code
}
#pragma GCC pop_options 



Let us know if this helps, and which of the solutions works for you when you've had chance to try it.
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint