From 639d90a0a4eb39d2631bd9ac8d5713486b877689 Mon Sep 17 00:00:00 2001
From: Per <Per Lindgren>
Date: Tue, 28 Feb 2017 10:14:16 +0000
Subject: [PATCH] doc

---
 README.md     | 21 ++++++++++++++++++++-
 include/SRP.h |  2 +-
 src/main.c    |  2 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index c85235d..1943ef2 100644
--- a/README.md
+++ b/README.md
@@ -38,16 +38,35 @@ Start the ITM tracing tool
 ```
 itmdump /tmp/swo.log
 ```
+Notice, the itmdump tool must be started BEFORE the openocd session (see Debug) in order to capture the ITM trace. 
 
 ## Debug 
 
 To run the program you will use the debugger integrated in eclipse. It uses openocd to communicate with the nucleo board, and gdb to 
 flash the image (generated .elf file) and interact (running, stepping, setting breakpoints etc.).
 
-Clic on the small green bug icon and select the d7020e_srp Debug oldgdb. (There other ways as well.)
+Click on the select the boxed `d7020e_srp Debug oldgdb` and click the boxed green bug icon. (There are other ways as well.)
 
 This will start openocd and gdb, and by default break at main. To execute the program to end, click the play icon.
 
 For further info on gdb debugging in eclipse see e.g., http://gnuarmeclipse.github.io/debug/
 
+The trace_printf is redirected to the ITM port, and you should get a trace of your program in the terminal.
+
+Notice, that setting breakpoints in the code may be a bit wonky, we use macros and that confuses the eclipse gdb interface. 
+The `BREAKPOINT` macro infers a compiler barrier that "should" allow you to put breakpoints in the code. Stepping in code that 
+is creating interrupts is also wonky, e.g., if sigle stepping over a `JOB_REQUEST` (that "pends" the corresponding interrupt handler), 
+the pend bit is correctly handeled. This is not a problem for this project only, but a general problem of the gdb integration, so 
+be aware.
+
+## Problems
+
+If openocd fails to start, one possible error is that the `/tmp/swo.log` file has been locked to a bad state. Actually its not an 
+ordinary file but rather a (linux/posix) FIFO, allowing the openocd to pipe data to the itmdump tool. You may want to stop the itmdump
+and restart it, and try to launch the debugger again.
+
+## Tips  
+
+ 
+
 
diff --git a/include/SRP.h b/include/SRP.h
index 86ffd3a..54ea8bd 100644
--- a/include/SRP.h
+++ b/include/SRP.h
@@ -34,5 +34,5 @@
 
 #define TASK(J)			void IRQh(J) ()
 
-
+#define BREAKPOINT      { asm volatile("" ::: "memory"); }
 
diff --git a/src/main.c b/src/main.c
index 7cd76dd..be522ca 100644
--- a/src/main.c
+++ b/src/main.c
@@ -38,6 +38,7 @@ int main() {
 	JOB_REQUEST(j1);			// comment out in assignment c
 	//JOB_REQUEST(j3);  		// use in assignment c
 
+	BREAKPOINT;
 	while (1) ;
 	return 0;
 }
@@ -47,6 +48,7 @@ TASK(j1) {
 	LOCK(r2);
 		JOB_REQUEST(j2); 			// job execution request for j2
 		trace_printf("j1 after job request j2\n");
+		BREAKPOINT;
 		LOCK(r1);
 			trace_printf("j1_r1_locked, before job request j2\n");
 			JOB_REQUEST(j2);
-- 
GitLab