I've been getting various issues while trying to set software breakpoints in Atmel Studio 7 with the Atmel-ICE debugger using SWD. I was wondering if anyone could explain in more detail (or point me in the direction of documentation) to give me a better understanding as to why I get the following issues:
Breakpoints being moved upon compilation
Being 'Unable to set requested breakpoint on target'
Breakpoint only being hit the first time in a loop
The following code is a test program I wrote to demonstrate this using the delay routines and the PORT driver of the ASF:
#include <asf.h>
#define LED PIN_PA01
int main (void)
{
system_init();
delay_init();
struct port_config config_port_pin;
config_port_pin.direction = PORT_PIN_DIR_OUTPUT;
port_pin_set_config(LED, &config_port_pin);
while(1)
{
port_pin_toggle_output_level(LED);
delay_ms(100);
}
}
If a breakpoint is set at the LED toggle line then the breakpoint is moved to the following delay line.
If the delay is commented out and a breakpoint placed at the LED toggle line then it tells me it is unable to set requested breakpoint on target
If a breakpoint is placed on the delay line it only gets hit (the program halts) on the first iteration of the while loop. If I continue (F5) the program keeps running ( LED toggles every 100 ms) but doesn't stop at the breakpoint.
The code runs fine as far as I'm aware. The LED toggles every 100 ms as expected when I run without debugging, it is just the software breakpoints that I don't quite understand, sorry for my ignorance.
i know you answered your problem but this is really good tutorial someone wrote
about optimization of compiler
https://www.avrfreaks.net/forum/tutcoptimization-and-importance-volatile-gcc
Related
The timer on Rung 0 should be timing but it is not.
The PLC is online and in live mode and the logic before the timer is true.
This is running on a CompactLogix L16ER.
Take a look at your first picture, the left-most rail of the ladder is not green. It looks like that entire routine is not running.
In your program properties for the program/task your using, go to "Program Properties" then to the "Configuration" Set your main program to the desired program you're trying to use.
I'm busy bring up some new hardware with a STM32F030C8 mcu. I'm using the STM32CubeIDE with gcc. I'm very new to microcontroller development and this is my first project with ST and their tools.
This is a very basic program that just triggers a GPIO. The rest is all generated code. As I have very little experience in this field I hope somebody can point to a location where I can look. I suspect that it might be a configuration issue.
Here is the code (I removed all generated comments to keep it a bit more compact):
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 1
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 2
while (1)
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2);
HAL_Delay(1000);
}
}
When I step through the code It will trigger the GPIO on "my code 1" once I step to "my code 2" it will cause the issue. I have even tried just running a fully generated program with no modifications and the issue persists. This was a quick test to see if the program actually does run on the mcu. And it does, as well as trigger the GPIO.
Debugger console Output:
Temporary breakpoint 1, main () at ../Core/Src/main.c:74
74 HAL_Init();
Program received signal SIGTRAP, Trace/breakpoint trap.
0x1fffecec in ?? ()
The Temporary breakpoint is where the program starts, I can then either run from there. Or step through, all with the same result.
Console Output:
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.4.0
-------------------------------------------------------------------
ST-LINK SN : 34FF6E065250343816210143
ST-LINK FW : V2J36S7
Voltage : 3.22V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x440
Device name : STM32F05x/F030x8
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M0
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_PEkdAh.srec
File : ST-LINK_GDB_server_PEkdAh.srec
Size : 4944 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.627
Verifying ...
Download verified successfully
Full Error:
Break at address "0x1fffecec" with no debug information available, or outside of program code.
Here is two images that might help. As I mention I'm very new to this. So any other information required please ask. Thanks in advance.
Debug View
Disassembly
The code is placed at 0x08000000. There is no user code at 0x1fffecec. It system area and probably it boots the system bootloader. It shows that the BOOTx pin is incorrectly connected.
I have a larger project for which I want to have function that if run, clicks 10 times as fast as possible at the current cursor location.
This kind of works on my desktop, for example I tried running the program in my terminal and had my cursor on the menu bar. But if I switch to another application however (I tried it with a game in window mode) (I first let my program sleep for 4 seconds so I have enough time to switch), it just clicks once. The game is a shooter, so it should fire a couple of times fast but it just fires once and ignores all other events.
If I let my program sleep for 1 sec between cycles, it works.
Maybe I used the CGEvents wrong? Is there a difference between using MouseEvents and actually clicking? I mean shouldn't it be exactly the same for the game?
Here is my isolated code:
// Compile with: gcc -o click test.c -Wall -framework ApplicationServices
#include <ApplicationServices/ApplicationServices.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
// To click on current position (seems to work)
CGEventRef event = CGEventCreate(NULL);
CGPoint cursor = CGEventGetLocation(event);
CGEventRef click_down = CGEventCreateMouseEvent(NULL, kCGEventLeftMouseDown, cursor, kCGMouseButtonLeft);
CGEventRef click_up = CGEventCreateMouseEvent(NULL, kCGEventLeftMouseUp, cursor, kCGMouseButtonLeft);
// Tried adding usleep between both events but anything under 1s doesnt work
for(int i = 0; i < 10; i++){
CGEventPost(kCGSessionEventTap, click_down);
// usleep(500);
CGEventPost(kCGSessionEventTap, click_up);
// usleep(500);
}
// Release the events
CFRelease(event);
CFRelease(click_down);
CFRelease(click_up);
}
What I read and tried but didn't help:
Simulate mouse on Mac
Simulating mouse clicks on Mac OS X does not work for some applications
-> Unfortunately didn't help or fix the problem
Synthetic click doesn't switch application's menu bar (Mac OS X)
I found the solution myself and it is really simple:
First of all I forgot that usleep is in microseconds and not miliseconds.
Furthermore apparently macOS buffers the clicks or keyboard inputs in the native environment but OpenGL doesn't. So of course it works if you pause for 1 second between clicks/keyboard presses but in OpenGL it just discards them if they are too fast. The solution is to wait the a small amount between clicks or keypresses. For me worked 100ms, that means usleep(100000), before and after the press down.
I'm trying to figure out why an WPF-app won't exit imediately on closing it. Using Process Explorer I hade found out that WerFault.exe is started while exiting which seem to indicate that something crashes during the teardown, perhaps some destructor or dispose that fails. This started happening when I recently switched to VS2015. I am running Windows 8.
My question is: How can I find out what the real problem is? Any way of finding a crash log for WerFault.exe? I have hundreds of destructors and dispose-methods so it's a bit hard to put breakpoints in all of them. Any other way of capturing these kinds of errors in VS?
The exit code is -1073740791 which "indicate a bug in the executed software that causes stack overflow, leading to abnormal termination of the software". But where?
Some more info from the event log:
Faulting module name: ucrtbase.DLL, version: 10.0.10240.16390, time stamp: 0x55a5b718
Exception code: 0xc0000409
Fault offset: 0x0000000000065a4e
You could try enabling user mode dumps:
Create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Within LocalDumps, create a key that is the name of your executable
Within the key you just created, set the values of DumpFolder, DumpCount, DumpType, and CustomDumpFlags as needed (you should definitely set DumpType to 2 for full dumps, otherwise I don't think that enough information will be captured to debug a managed dump).
Once you have done this, whenever your executable crashes a dump file will be created in the folder specified by DumpFolder (or %LOCALAPPDATA%\CrashDumps by default).
I have a complex cgi executable written in C, I configured in Apache2 and now it is running succesfully. How can I debug this program in the source code, such as set break points and inspect variables? Any tools like gdb or eclipse? Any tutorial of how to set up the debugging environment?
Thanks in advance!!
The CGI interface basically consists in passing the HTTP request to the executable's standard input and getting the response on the standard output. Therefore you can write test requests to files and manually execute your CGI without having to use Apache. The debugging can then be done with GDB :
gdb ./my_cgi
>> break some_func
>> run < my_req.txt
with my_req.txt containing the full request:
GET /some/func HTTP/1.0
Host: myhost
If you absolutely need the CGI to be run by Apache it may become tricky to attach GDB to the right process. You can for example configure Apache to have only one worker process, attach to it with gdb -p and use set follow-fork-mode child to make sure it switches to the CGI process when a request arrives.
I did this: in cgi main i added code to look for an existing file, like /var/tmp/flag. While existing, i run in a loop. Time enough to attach to cgi process via gdb. After then i delete /var/tmp/flag and from now I can debug my cgi code.
bool file_exists(const char *filename)
{
ifstream ifile(filename);
return ifile;
}
int cgiMain()
{
while (file_exists ("/var/tmp/flag"))
sleep (1);
...
your code
Unless FastCGI or SCGI is used, the CGI process is short-lived and you need to delay its exit to have enough time to attach the debugger while the process is still running. For casual debugging the easiest option is to simply use sleep() in an endless loop at the breakpoint location and exit the loop with the debugger once it is attached to the program.
Here's a small example CGI program:
#include <stdio.h>
#include <unistd.h>
void wait_for_gdb_to_attach() {
int is_waiting = 1;
while (is_waiting) {
sleep(1); // sleep for 1 second
}
}
int main(void) {
wait_for_gdb_to_attach();
printf("Content-Type: text/plain;charset=us-ascii\n\n");
printf("Hello!");
return 0;
}
Suppose it is compiled into cgi-debugging-example, this is how you would attach the debugger once the application enters the endless loop:
sudo cgdb cgi-debugging-example $(pgrep cgi-debugging)
Next you need to exit the infinite loop and wait_for_gdb_to_attach() function to reach the "breakpoint" in your application. The trick here is to step out of sleep functions until you reach wait_for_gdb_to_attach() and set the value of the variable is_waiting with the debugger so that while (is_waiting) exits:
(gdb) finish
Run till exit from 0x8a0920 __nanosleep_nocancel () at syscall-template.S:81
0x8a07d4 in __sleep (seconds=0) at sleep.c:137
(gdb) finish
Run till exit from 0x8a07d4 in __sleep (seconds=0) at sleep.c:137
wait_for_gdb_to_attach () at cgi-debugging-example.c:6
Value returned is $1 = 0
(gdb) set is_waiting = 0 # <<<<<< to exit while
(gdb) finish
Run till exit from wait_for_gdb_to_attach () cgi-debugging-example.c:6
main () at cgi-debugging-example.c:13
Once you are out of wait_for_gdb_to_attach(), you can continue debugging the program or let it run to completion.
Full example with detailed instructions here.
I'm not sure how to use gdb or other frontends in eclipse, but I just debugged my CGI program with gdb. I'd like to share something that other answers didn't mention, that CGIs usually need to read request meta-variables defined in RFC 3875#4.1 with getenv(3). Popular request variables in my mind are:
SCRIPT_NAME
QUERY_STRING
CONTENT_LENGTH
CONTENT_TYPE
REMOTE_ADDR
There variables are provided by http servers such as Apache. When debugging with gdb, we need to set these values by our own with set environment. In my case, there're only a few variables neededa(and the source code is very old, it still uses SCRIPT_URL instead of SCRIPT_NAME), so here's my example:
gdb cgi_name
set environment SCRIPT_URL /path/to/sub/cgis
set environment QUERY_STRING p1=v1&p2=v2
break foo.c:42
run
For me both solutions for debugging the CGI in gdb without web server presented above didn't work.
Maybe the second solution works for a GET Request.
I needed a combination of both, first setting the environment variables from rfc3875 (not sure if all of them are really neded).
Then I was able to pass only the params (not the compltete request) via STDIN from a file.
gdb cgi_name
set environment REQUEST_METHOD=POST
set environment CONTENT_LENGTH=1337
set environment CONTENT_TYPE=application/json
set environment SCRIPT_NAME=my.cgi
set environment REMOTE_ADDR=127.0.0.1
run < ./params.txt
With params.txt:
{"user":"admin","pass":"admin"}