V3.5.0

docs/changelog.md

@@ -1,6 +1,6 @@
 # Changelog for dw-link
 
-## Version 3.4.1
+## Version 3.5.0
 
 * Changed minimal initial bps for DW line from 10 to 5 in expectUCalibrate
 * Changed timeout from 100000 to 300000 in expectBreakAndU
@@ -10,6 +10,7 @@
 * Use now sendCmd in class dwSerial instead of sendCommand as a function in dw-link
 * sendCmd has a new optional last parameter, which when true, will finish early; default is false
 * In all cases, when a response or a break is expected, we now finish early, and the cases that led to problems are now OK.
+* Changed MAXBREAK from 33 to 25 (meaning 80 additional free bytes!) because otherwise we had only 10 bytes of free memory when TXODEBUG was active, which actually led to a crash! I never ever used 32 breakpoints and even 25 are probably too many.
 
 ## Version 3.4.0 (12-Sep-2023)
 

docs/manual.md

@@ -714,7 +714,7 @@ Fifth, when reprogramming of a flash page is requested, dw-link first checks whe
 
 With all of that in mind, you do not have to worry too much about flash memory wear when debugging. As a general rule, you should not make massive changes of the breakpoints each time the MCU stops executing. Finally, Microchip recommends that chips that have been used for debugging using debugWIRE should not been shipped to customers. Well, I never ship chips to customers anyway.
 
-<a name="paranoid"></a>For the really paranoid,  there is the option that permits only one breakpoint, i.e., the hardware breakpoint: `monitor breakpoint h`. In this case, one either can set one breakpoint or on can single-step, but not both. So, if you want to continue after a break by single-stepping, you first have to delete the breakpoint. By the way, with `monitor breakpoint s`, one switches back to normal mode, in which 32 (+1 temporary) breakpoints are allowed.
+<a name="paranoid"></a>For the really paranoid,  there is the option that permits only one breakpoint, i.e., the hardware breakpoint: `monitor breakpoint h`. In this case, one either can set one breakpoint or on can single-step, but not both. So, if you want to continue after a break by single-stepping, you first have to delete the breakpoint. By the way, with `monitor breakpoint s`, one switches back to normal mode, in which 25 (including one temporary) breakpoints are allowed.
 
 In addition, there is the debugger command `monitor flashcount`, which returns the number of how many flash page reprogramming commands have been executed since the debugger had been started. This includes also the flash reprogramming commands needed when loading code.
 
@@ -742,7 +742,7 @@ In many debuggers, it is impossible to do single-stepping when timer interrupts
 
 ### 8.5 Limited number of breakpoints
 
-The hardware debugger supports only a limited number of breakpoints. Currently, 32 breakpoints (+1 temporary breakpoint for single-stepping) are supported by default. You can reduce this to 1 by issuing the command `monitor breakpoint h` ([see above](#paranoid)). If you set more breakpoints than the maximum number, it will not be possible to start execution. Instead one will get the warning `Cannot insert breakpoint ... Command aborted`. You have to delete or disable some breakpoints before program execution can continue. However, you should not use that many breakpoints in any case. One to five breakpoints are usually enough. 
+The hardware debugger supports only a limited number of breakpoints. Currently, 25 breakpoints (including one temporary breakpoint for single-stepping) are supported by default. You can reduce this to 1 by issuing the command `monitor breakpoint h` ([see above](#paranoid)). If you set more breakpoints than the maximum number, it will not be possible to start execution. Instead one will get the warning `Cannot insert breakpoint ... Command aborted`. You have to delete or disable some breakpoints before program execution can continue. However, you should not use that many breakpoints in any case. One to five breakpoints are usually enough. 
 
 ### 8.6 Power saving is not operational 
 
@@ -869,7 +869,7 @@ One reason for that could be that the target is run with a clock less than 1 MHz
 
 #### Problem: The debugger does not start execution when you request *single-stepping* or *execution* and you get the warning *Cannot insert breakpoint ... Command aborted* 
 
-You use more than the allowed number of breakpoints, i.e., usually 32 (+1 for a temporary breakpoint for single-stepping). If you have executed the `monitor breakpoint h` command, this number is reduced to 1. In this case, you can either set a breakpoint or you can single-step, but not both! In any case, you need to reduce the number of breakpoints before you can continue.
+You use more than the allowed number of breakpoints, i.e., usually 25 (including one for a temporary breakpoint for single-stepping). If you have executed the `monitor breakpoint h` command, this number is reduced to 1. In this case, you can either set a breakpoint or you can single-step, but not both! In any case, you need to reduce the number of breakpoints before you can continue.
 
 #### Problem: When single stepping with `next` or `step` , you receive the message *Warning: Cannot insert breakpoint 0* and the program is stopped at a strange location
 
@@ -1050,4 +1050,5 @@ Initial version
 
 * Redesign of monitor commands; most of them now take an argument
 * Disabling automatic mode switching (Section 2)
-* Lowest frequency is now 4kHz (Section 8.7)
+* Lowest frequency is now 4kHz (Section 8.7)
+* Number of breakpoints reduced from 33 to 25 because of stability problems (when debugging was on)

dw-link/dw-link.ino

@@ -35,7 +35,7 @@
 // because relevant input ports are not in the I/O range and therefore the tight timing
 // constraints are not satisfied.
 
-#define VERSION "3.4.0"
+#define VERSION "3.5.0"
 
 // some constants, you may want to change
 #ifndef PROGBPS
@@ -52,9 +52,9 @@
 // these should stay undefined for the ordinary user
 // #define CONSTDWSPEED 1     // constant communication speed with target
 // #define OFFEX2WORD 1       // instead of simu. use offline execution for 2-word instructions
-#define TXODEBUG 1         // allow debug output over TXOnly line
+// #define TXODEBUG 1         // allow debug output over TXOnly line
 // #define SCOPEDEBUG 1       // activate scope debugging on PORTC
-// #define FREERAM  1         // measure free ram
+#define FREERAM  1         // measure free ram
 // #define UNITALL 1          // enable all unit tests
 // #define UNITDW 1           // enable debugWIRE unit tests
 // #define UNITTG 1           // enable target unit tests
@@ -94,7 +94,7 @@
 #define MAXBUF 160 // input buffer for GDB communication (enough for initial packet in gdb 12.1)
 #define MAXMEMBUF 150 // size of memory buffer
 #define MAXPAGESIZE 256 // maximum number of bytes in one flash memory page (for the 64K MCUs)
-#define MAXBREAK 33 // maximum of active breakpoints (we need double as many entries for lazy breakpoint setting/removing!)
+#define MAXBREAK 25 // maximum of active breakpoints (we need double as many entries for lazy breakpoint setting/removing!)
 
 // communication bit rates 
 #define SPEEDHIGH     300000UL // maximum communication speed limit for DW

dw-link/src/dwSerial.cpp

@@ -56,9 +56,9 @@ unsigned long dwSerial::calibrate()
   byte edges;
   byte saveSREG;
 
-  DDRC = 1;
-  PORTC |= 1;
-  PORTC &= ~1;
+  //DDRC = 1;
+  //PORTC |= 1;
+  //PORTC &= ~1;
   saveSREG = SREG;
   cli();
   enable(false);
@@ -68,13 +68,13 @@ unsigned long dwSerial::calibrate()
   TIFR |= _BV(ICF);
   TIFR |= _BV(TOV);
 
-  PORTC |= 1;
-  PORTC &= ~1;
+  //PORTC |= 1;
+  //PORTC &= ~1;
   while ((TIFR & _BV(ICF)) == 0  && timeout) { // wait for first falling edge
     timeout--;
   }
-  PORTC |= 1;
-  PORTC &= ~1;
+  //PORTC |= 1;
+  //PORTC &= ~1;
   TCNT = 0; // reset timer so that we do not have to worry about TOV
             // we probably start 12 cycles late because of the reset
   if (timeout == 0) {