From: norly <ny-git@enpas.org>
Date: Mon, 18 Feb 2019 13:23:33 +0000 (+0100)
Subject: Work around hardware bug when waiting for '>' prompt
X-Git-Url: https://git.enpas.org/?a=commitdiff_plain;h=92d4b039f00cce7788a608b63f6ae1d53d17722d;p=elmcan.git

Work around hardware bug when waiting for '>' prompt

Sometimes the ELM327 sets 0x80 and/or 0x40 when sending '>' to indicate
that it is ready to receive the next command.

Masking these two bits out seems to take care of most or all hangs
during initialization.
---

diff --git a/module/elmcan.c b/module/elmcan.c
index ffdb60e..e0a2fde 100644
--- a/module/elmcan.c
+++ b/module/elmcan.c
@@ -673,7 +673,8 @@ static void elm327_parse_rxbuf(struct elmcan *elm)
 				elm->state = ELM_GETPROMPT;
 				i++;
 				break;
-			} else if (elm->rxbuf[i] == ELM327_READY_CHAR) {
+			} else if ((elm->rxbuf[i] & 0x3f) == ELM327_READY_CHAR) {
+				/* Mask 0xc0 to work around hardware bugs */
 				elm327_send(elm, ELM327_MAGIC_STRING, 1);
 				i++;
 				break;
@@ -686,8 +687,11 @@ static void elm327_parse_rxbuf(struct elmcan *elm)
 	}
 
 	case ELM_GETPROMPT:
-		/* Wait for '>' */
-		if (elm->rxbuf[elm->rxfill - 1] == ELM327_READY_CHAR) {
+		/* Wait for '>'.
+		 * Bits 0xc0 are sometimes set (randomly), hence the mask.
+		 * Probably bad hardware.
+		 */
+		if ((elm->rxbuf[elm->rxfill - 1] & 0x3f) == ELM327_READY_CHAR) {
 			elm327_handle_prompt(elm);
 		}