Add logic and message to alert when communication lost

[PropGit]

[This request created in response to Issue #27]

In much the same way that the added "Propeller not found" error message clarifies download failures, we need a Communication lost message.

• Add fatal error message, "Communication lost" and give it the next available error code.
• Add logic to emit that message when no response is received in the total time expected (beginning after the Propeller's version response was successfully received and verified, and ending at the point of finishing communication
  • Example moments to emit this message:
    • Verifying RAM, but fatally timed-out because no response received
    • Verifying EEPROM, but fatally timed-out because no response received
    • Transmitting Propeller Application image packets, but fatally timed-out because no response received to latest attempt/re-sends

This should apply to both wired and wireless downloads and should appear before the "ERROR: Download failed: -1" message so that instead of something like this:

001-Opening file '../myfile.binary'
002-Downloading file to port ...
009-... bytes sent
003-Verifying RAM
102-ERROR: Download failed: -1

we see this (assuming no response was received for the RAM checksum and assuming the error code is 126):

001-Opening file '../myfile.binary'
002-Downloading file to port ...
009-... bytes sent
003-Verifying RAM
126-ERROR: Communication lost
102-ERROR: Download failed: -1

[dbetz]

What about other reasons for the protocol failing? Currently, the TransmitPacket function can fail if it tries 3 times and each attempt gets a timeout. It can also fail if it gets data but the packet ID or tag is wrong. Do we want errors for each of those cases?

[PropGit]

Yes, other reasons for protocol failing at that point were intended to be covered by this issue too. For the timeout cases, they can result in the example I gave "126-ERROR: Communication lost."

Actually, even the case where it gets the wrong packet ID or the tag is wrong... those can also use the same "126-ERROR: ..." result. If we need to know more, we can use the verbose option to see that it did indeed receive something, but it was an unexpected result.

This way, we don't need 10 new error codes (1 to cover each case), but perhaps much fewer (1, 2 or 3 maybe) that nicely covers all cases. Let me know if you question certain error cases and what error to emit.

NOTE: 126 was just the next error code at the time of this issue's creation; it should be set to the proper value when created.

[dbetz]

I currently have three errors that could fall into this category:

RX handshake timeout
RAM checksum timeout
EEPROM checksum timeout

Do you want all of these to produce the "Communication lost" error?

[dbetz]

done

[PropGit]

Did you implement each of those three with a single "Communication lost" error? That was the intent, yes.

[PropGit]

Verified on v1.0-37.