|Anonymous | Login | Signup for a new account||2020-06-03 13:00 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000463||Firmware||Serial Comms||public||2011-12-04 21:30||2011-12-10 17:57|
|Target Version||0.2.0||Fixed in Version||0.2.0|
|Summary||0000463: Losing Large Chunks Of Packets < 2% Affected|
|Description||Periodically big 50 byte chunks of packets get lost and the result is often large 150 ish byte packets being discarded with a bad checksum, or small 50 byte ish packets being discarded with a bad checksum. Need to track this down and solve it ASAP.|
|Tags||No tags attached.|
|Risk of Breakage||medium|
|New info: Just noticed the LED on the FTDI flashing off for significant periods of time and reviewed a bin log in OLV and found that there are large chunks of packets missing, so the bad ones that we are seeing are the end and beginning of the dead zone joining back together! :-/ Hmmmm.|
Set count before checking in a while(reg) loop and diff count for a wait time to send out in each log and see if it actually waits. It coudl be that we need to read the reg to get the first byte to send properly. Who knows, buggy hw perhaps?
Parallel saleae and bin logs reveal that whilst the main loop code thinks that its sending 8 packets it really is only sending one, the bug appears to be in the main loop code as when this happens there is a longer delay between datalog packets.
Additionally, last night I found some room for improvements in the interrupt code, which I'll apply after I resolve this issue.
|Fixed in 64e0844bc935fd6da3fef7d5e7ea6924793d65b6.|
|Copyright © 2000 - 2011 MantisBT Group|