V1.3.10

docs/changelog.md

@@ -666,3 +666,10 @@ this is needed by the original Arduino Nano
 
 - New `monitor help` command
 - Added some additional trouble shooting hints concerning debugging when lock-bits are set.
+
+## Version 1.3.10 (12-Mar-22)
+
+- added monitor dwconnect to the startup sequence of the debugger in platformio.ini so that one gets a meaningful error message when the connection cannot be established
+- added new task Erase Chip to PIOs Custom tasks which can be used to clear lock bits
+- reduced debouncing in configureSupply to 5ms so that we do not lose input from the debugger when establishing the connection (and at SNSGND we read a 0)
+- 

docs/manual.md

@@ -4,7 +4,7 @@
 
 **Bernhard Nebel**
 
-**Version 1.9 - February, 2022**
+**Version 1.10 - March, 2022**
 
 <a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.
 
@@ -196,12 +196,14 @@ ATtiny pin# | Arduino Uno pin | component
   | D7 |system LED (+)
   | D6 |200 Ω to system LED (-)
 
-We are now good to go and 'only' need to install the additional debugging software. Before we do that, let us have a look, in which states the debugger can be and how it signals that using the system LED.
 
-If instead of an ATtiny85, you want to debug an Uno board, everything said above applies here as well. A Fritzing sketch showing you the connections is below. Remember to cut the `RESET EN` solder bridge on the target board (see [Section 3.3](#section33))!
+
+If instead of an ATtiny85, you want to debug an Uno board, everything said above applies here as well. A Fritzing sketch showing you the connections is below. Remember to cut the `RESET EN` solder bridge on the target board (see [Section 3.3](#section33))! Further, the first time, you debug a Uno target, you probably cannot establish a connection, i.e., after using the `target remote` command, a fatal error is signaled by the system LED. The reason is that on the ATmega chip [*lock bits*](https://microchipsupport.force.com/s/article/Use-of-Lock-Bits-in-AVR-devices) have been set. These can be cleared by erasing the chip memory using the debugger command `monitor erase` (see [command table](#monitor-commands)).
 
 ![Uno as DUT](pics/Debug-Uno.png)
 
+We are now good to go and 'only' need to install the additional debugging software. Before we do that, let us have a look, in which states the debugger can be and how it signals that using the system LED.
+
 ### 4.3 States of the hardware debugger
 
 There are four states, the debugger can be in and each is signaled by a different blink pattern of the system LED:
@@ -235,7 +237,6 @@ __UNITTG__ | 0 | If 1, the unit tests for the target layer are activated; use `m
 __UNITGDB__ | 0 | If 1, the unit tests for the GDB layer are activated, use `monitor testgdb` to execute them. 
 __ARDUINO\_AVR\___*XXX* | undef | These constants are set when using the compile command of the Arduino IDE or CLI. They determine the pin mapping if an adapter board or shield is used (see [Section 7.3.2 & 7.3.3](#section732)). 
 
-
 <a name="section5"></a>
 
 ## 5. Arduino IDE and avr-gdb
@@ -814,15 +815,9 @@ Something in the `platformio.ini` file is not quite right. Perhaps a missing dec
 
 One common problem is that the debug environment is not the first environment or the default environment. In this case, the wrong environment is used to configure the debug session and probably some environment variables are not set at all or set to the wrong values. So, you need to edit the `platformio.ini` file accordingly.
 
-Another common problem is that the connection to the target cannot be established. If you want to get some diagnostics, you can start `avr-gdb` stand-alone (under Windows search for the program name and then select it for execution). Then type the the following sequence of commands (*serialport* being the serial port to the debugger):
+Another common problem is that the connection to the target cannot be established. In this case, you should see the appropriate error message. 
 
-```
-set serial baud 115200
-target remote serialport
-monitor dwconnect
-```
-
-This should show you the connection problem. If the error message is *Connection error: Lock bits are set*, then you can erase the chip by issuing the command `monitor erase`.
+If the error message is *Connection error: Lock bits are set*, then you need to erase the chip before you can use the debugger. Go to the PlatformIO `Custom` tasks and choose `Erase Chip`.
 
 #### Problem: When connecting to the target using the *target remote* command, it takes a long time and then you get the message *Remote replied unexpectedly to 'vMustReplyEmpty': timeout*
 
@@ -836,7 +831,7 @@ Depending on the concrete error message, the problem fix varies.
 
 - *Cannot connect: Check wiring*: The debugger can neither establish an ISP nor debugWIRE connection. Check wiring. It could also be a problem with the RESET line (see [Section 3.3](#section33)).
 - *Cannot connect: Unsupported MCU*: This MCU is not supported by dw-link. It most probably has no debugWIRE connectivity. 
-- *Cannot connect: Lock bits are set*: In this case you need to erase the entire chip before you can debug it. You can do that by issuing `monitor erase`. 
+- *Cannot connect: Lock bits are set*: In this case you need to erase the entire chip before you can debug it. You can do that by issuing `monitor erase`. After that, you should restart the debugger.
 - *Cannot connect: PC with stuck-at-one bits*: This is most probably an MCU with stuck-at-one bits in the program counter (see [Section 8.9](#section89)). These MCUs cannot be debugged with GDB. 
 - *Cannot connect for unknown reasons:* This error message should not be shown at all. If it does, please tell me!
 
@@ -865,6 +860,8 @@ Another reason may be that the communication speed between hardware debugger and
 
 You can choose 230400, 115200, 57600, 38400, 19200, or 9600 when starting `avr-gdb` by giving the bit rate as an argument to the `-b` option or by specifying the bit rate as an argument to the command `set serial baud ...` before establishing a connection with the `target` command.
 
+Note that you need to reset the hardware debugger if you want to communicate using a different bit rate. 
+
 #### 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 hwbp` 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.
@@ -1012,3 +1009,8 @@ Initial version
 
 - Additional trouble shooting help when lockouts are set
 
+#### V 1.10
+
+- Pointed out in Section 4.2 that when debugging an Uno the first time you try to debug it, you need to erase the chip in order to clear the lock bits.
+- Added similar wording under trouble shooting
+

dw-link/dw-link.ino

@@ -39,7 +39,7 @@
 // For the latter, I experienced non-deterministic failures of unit tests.
 // So, it might be worthwhile to investigate both, but not now.
 
-#define VERSION "1.3.9"
+#define VERSION "1.3.10"
 
 #ifndef NANOVERSION
 #define NANOVERSION 3
@@ -533,7 +533,7 @@ void unblockIRQ(void)
 /******************* main ******************************/
 int main(void) {
   // Arduino init
-   init();
+  init();
 #if defined(USBCON)
   USBDevice.attach();
 #endif
@@ -564,7 +564,8 @@ int main(void) {
   pinMode(pm.VSUP, OUTPUT);
   digitalWrite(pm.VSUP, HIGH);
 #if SCOPEDEBUG
-  DDRC = 0x7F; //
+  pinMode(pm.DEBTX, OUTPUT); //
+  digitalWrite(pm.DEBTX, LOW); // PD3 on UNO
 #endif
   initSession(); // initialize all critical global variables
   //  DEBLN(F("Now configuereSupply"));
@@ -574,10 +575,11 @@ int main(void) {
   digitalWrite(pm.TISP, HIGH); // disable outgoing ISP lines
   pinMode(DWLINE, INPUT); // release RESET in order to allow debugWIRE to start up
 #if CONSTHOSTSPEED == 0
-  detectRSPCommSpeed(); // check for coummication speed and select the right one
+  detectRSPCommSpeed(); // check for communication speed and select the right one
+  Serial.end();
+  Serial.begin(ctx.hostbps);
 #endif
   DEBLN(F("Setup done"));
-
   // loop
   while (1) {
     monitorSystemLoadState();
@@ -587,16 +589,7 @@ int main(void) {
     } else if (ctx.state == RUN_STATE) {
       if (dw.available()) {
 	byte cc = dw.read();
-#if SCOPEDEBUG
-	PORTC |= 0x02;
-	PORTC &= ~0x02;
-#endif
 	if (cc == 0x0) { // break sent by target
-#if SCOPEDEBUG
-	  PORTC |= 0x02;
-	  PORTC |= 0x02;
-	  PORTC &= ~0x02;
-#endif
 	  if (expectUCalibrate()) {
 	    DEBLN(F("Execution stopped"));
 	    _delay_us(5); // avoid conflicts on the line
@@ -665,6 +658,7 @@ void detectRSPCommSpeed(void) {
 	return;
       }
     }
+    Serial.end();
     Serial.begin(INITIALBPS); // set to initial guess and wait again
   }
 }
@@ -674,11 +668,12 @@ void detectRSPCommSpeed(void) {
 boolean rightSpeed(void)
 {
   char keyseq[] = "qSupported:";
+  const int maxix = strlen(keyseq);
   int ix = 0;
-  const int maxix = sizeof(keyseq) - 1;
   int timeout;
   char c;
 
+  DEBLN(F("rightSpeed"));
   measureRam();
   timeout = 2000;
   while (timeout-- && ix < maxix) 
@@ -690,13 +685,15 @@ boolean rightSpeed(void)
 	if (c == keyseq[0]) ix = 1;
 	else ix = 0;
     }
+  DEBPR(F("Rec loop finished. ix = ")); DEBLN(ix);
   // now read the remaining chars
   timeout = 2000;
   while (timeout--)
     if (Serial.available()) {
       timeout = 2000;
       Serial.read();
     }
+  DEBPR(F("rightSpeed returns: ")); DEBLN(ix == maxix);
   return (ix == maxix); // entire sequence found
 }
 
@@ -705,7 +702,11 @@ void configureSupply(void)
 {
   if (digitalRead(SNSGND)) return; 
   if (ctx.vhigh != !digitalRead(pm.VHIGH) || ctx.von != !digitalRead(pm.VON)) { // something changed
-    _delay_ms(30); // debounce
+#if SCOPEDEBUG
+  PORTD |= _BV(PD3);
+  PORTD &= ~_BV(PD3);
+#endif
+    _delay_ms(5); // debounce
     //DEBLN(F("Some change"));
     //DEBPR(F("VHIGH: ")); DEBPR(ctx.vhigh); DEBPR(F(" -> ")); DEBLN(!digitalRead(pm.VHIGH));
     //DEBPR(F("VON:   ")); DEBPR(ctx.von); DEBPR(F(" -> ")); DEBLN(!digitalRead(pm.VON));
@@ -788,7 +789,7 @@ void gdbHandleCmd(void)
 {
   byte checksum, pkt_checksum;
   byte b;
-  
+
   measureRam();
   b = gdbReadByte();