Open riedel opened 11 years ago
Fixes part of the problem:
index df78b24..2b499c3 100644
--- a/con_serial.py
+++ b/con_serial.py
@@ -101,6 +101,9 @@ class SerialBootloader(JennicProtocol):
return []
try:
+ self.ser.timeout = 0
+ if(len(self.ser.read(1024))>0):
+ print "warning stray bytes"
self.ser.timeout = self.DEFAULT_TIMEOUT
self.ser.write(msg)
n,ans = ord(self.ser.read(1)), ""
@@ -112,6 +115,13 @@ class SerialBootloader(JennicProtocol):
n,ans = ord(self.ser.read(1)), ""
while len(ans)<n:
ans += self.ser.read(n)
+
+ if ord(ans[0])!=anstype:
+ raise Exception("wrong answer (0x%x) "%ord(ans[0]))
+
+ if 0!=self.crc(map(ord,ans[1:-1]), len(ans)-2):
+ raise Exception("crc failed")
+
return map(ord,ans[1:-1])
def finish(self):
very odd, this looks like the jennic has not been put into programming mode in the first post.
Also what's the rationale behind the your patch?
@@ -101,6 +101,9 @@ ->after setting the baud rate sometime there is still the return command (0x28) in the serial buffer. The logic then chokes
@@ -112,6 +115,13 @@ this part only catches the problems where they exist. Both return type and crc are not checked on answer messages (anstype isn't even) used.
Both could also be used as preparations for a retry logic.
BTW: the jennic seems to be brought into programming mode pretty consistently (looking at the toggling of the leds)
good catch, the baudrate setting problem is actually (supposed) to be solved in line 76, but the serial timeout maybe too low for that. I'll apply the patch soon, as it makes the whole thing more robust.
On Wed, Jul 24, 2013 at 12:02:00AM -0700, Till Riedel wrote:
@@ -101,6 +101,9 @@ ->after setting the baud rate sometime there is still the return command (0x28) in the serial buffer. The logic then chokes
@@ -112,6 +115,13 @@ this part only catches the problems where they exist. Both return type and crc are not checked on answer messages (anstype isn't even) used.
BTW: the jennic seems to be brought into programming mode pretty consistently (looking at the toggling of the leds)
Reply to this email directly or view it on GitHub: https://github.com/pscholl/jenprog/issues/2#issuecomment-21467219
Probably not only jenprog related.
Just for anybody else to confirm or close:
jenprog seems to work very unreliably on on a linux vm with 3.8 kernel.
Linux precise64 3.8.0-19-generic #30~precise1-Ubuntu SMP Wed May 1 22:26:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
e.g. mostly
File "/home/vagrant/jenprog/flashutils.py", line 57, in identify_flash self.flash_manufacturer = flash[1]
IndexError: list index out of range
or communication always times out