28-10-2021, 06:47 AM
28-10-2021, 06:54 AM
Sure.
https://drive.google.com/file/d/1FgYnFTH...sp=sharing
A possible small bug:
if there is only a single line in the while(1) cycle, the single step doesn't stop, but keeps "auto stepping". :-)
https://drive.google.com/file/d/1FgYnFTH...sp=sharing
A possible small bug:
if there is only a single line in the while(1) cycle, the single step doesn't stop, but keeps "auto stepping". :-)
28-10-2021, 06:59 AM
You have a compiler warning, those warnings are important
Your problem is not EBmonitor related but your C code, you have to include <stdio.h>
Your problem is not EBmonitor related but your C code, you have to include <stdio.h>
Code:
#include "main.h"
#include <stdio.h>
int a,b;
int main(void)
{
printf("\f");
while(1)
{
a++;
b=a*a;
printf("Hello World!\n");
}
}28-10-2021, 07:02 AM
The uC is an STM32F103C8T6. I have original and fake versions as well. The original STLink v3 and v3 mini doesn't like the counterfeit processors, but the v2 is working with them too.
I included, nothing changed except the warning.
I included, nothing changed except the warning.
28-10-2021, 07:07 AM
Well, your project is working here without any problems if I include that <stdio.h>.
28-10-2021, 07:10 AM
Unfortunately not working here. Live variables are working, but the EBMonitor window is empty.
28-10-2021, 07:14 AM
Is it empty or is it showing the text how to enable it? That's a big difference.
In the first situation it can find the variables but doesn't get any data. In the second, the variables are not found (missing).
In the first situation it can find the variables but doesn't get any data. In the second, the variables are not found (missing).
28-10-2021, 07:16 AM
About:
if there is only a single line in the while(1) cycle, the single step doesn't stop, but keeps "auto stepping". :-)
That's GDB related
if there is only a single line in the while(1) cycle, the single step doesn't stop, but keeps "auto stepping". :-)
That's GDB related
28-10-2021, 07:20 AM
EBMonitor is empty.
(To be on the safe side, I test with an original STLinkv3mini.)
If I run the program, EBMonitor works. But not in single step mode.
As I allways tested it in single step mode, didn't observed that until now. I added a breakpoint on EBmonitor_kbhit(), and observed, that single stepping that part, it wrotes to the EBMonitor window.
Then I run the code, and it wrotes to EBMonitor. Single stepping in the Main() still not write to EBMonitor.
(To be on the safe side, I test with an original STLinkv3mini.)
If I run the program, EBMonitor works. But not in single step mode.
As I allways tested it in single step mode, didn't observed that until now. I added a breakpoint on EBmonitor_kbhit(), and observed, that single stepping that part, it wrotes to the EBMonitor window.
Then I run the code, and it wrotes to EBMonitor. Single stepping in the Main() still not write to EBMonitor.
28-10-2021, 08:11 AM
Single step is working but you are impatient, you have to step some more lines (in your case 1 line) till it become visible.
You are facing two different things here:
1) How printf in newlib is working
2) How EBmonitor is working
1) printf doesn not always flush out everything right away. But if you have a newline then most likely it will flush the line. This depends how the buffering is set.
2) EBmonitor normally stops when the debugger stops and will poll the pipe on a live time ticker. event.
If you turn on "High-performance" it will poll te pipe constantly instead of using the live time ticker.
The latest consumes more bandwidth of the interface.
With "High-performance" EBmonitor is still paused on debugger stop but you have more chance that it has pulled the data before it stops.
Normally when you are using printf you won't notice a time difference of 250ms.
If you need tight synchronisation between printf and output then you should use semihosting. Semihosting uses a breakpoint and hold the target till the info is taken by the host.
You are facing two different things here:
1) How printf in newlib is working
2) How EBmonitor is working
1) printf doesn not always flush out everything right away. But if you have a newline then most likely it will flush the line. This depends how the buffering is set.
2) EBmonitor normally stops when the debugger stops and will poll the pipe on a live time ticker. event.
If you turn on "High-performance" it will poll te pipe constantly instead of using the live time ticker.
The latest consumes more bandwidth of the interface.
With "High-performance" EBmonitor is still paused on debugger stop but you have more chance that it has pulled the data before it stops.
Normally when you are using printf you won't notice a time difference of 250ms.
If you need tight synchronisation between printf and output then you should use semihosting. Semihosting uses a breakpoint and hold the target till the info is taken by the host.