From 92d4b039f00cce7788a608b63f6ae1d53d17722d Mon Sep 17 00:00:00 2001 From: norly Date: Mon, 18 Feb 2019 14:23:33 +0100 Subject: [PATCH] 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. --- module/elmcan.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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); } -- 2.30.2