|Anonymous | Login | Signup for a new account||2019-01-23 02:52 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000503||Firmware||Serial Comms||public||2012-01-15 16:41||2012-01-26 17:07|
|Target Version||0.2.0||Fixed in Version||0.2.0|
|Summary||0000503: Device Stops Responding To Packets|
|Description||But keeps functioning normally otherwise. Seems like a bug in the comms code that enters a state that it can't get out of perhaps by not setting or clearing a flag or something.|
|Additional Information||Noticed this in bench test hack, however could be applicable to other firmwares too, as most code is 100% common.|
|Tags||No tags attached.|
|Risk of Breakage||medium|
I've looked over the code and can't see anything obviously wrong.
If spudmn's observation of 6ms interrupt run times is accurate then that would prevent communications being received due to time out. I just tested this theory with 250ms inter char delay in cutecom and failed to get a response so I doubt that's the issue. I doubted it anyway, but this makes it SO utterly unlikely that it's almost impossible.
OK, source of this has been tracked down. This can only happen when the comms ISR runs late and misses the first byte. In particular, only if it gets another interrupt request at an inappropriate time. There is a bit of wrong logic in the error handling code somewhere that causes the flag to go uncleared. On the other hand, I should have this issue cleared up soon :-)
That lonely bump on channel 3 is an overrun. Before, that would have resulted in dead comms. Will tidy commit and push and close soon.
|Fixed in git hash 086624c87760ef02646aaa543dc5f633d4d9d02a|
|Copyright © 2000 - 2011 MantisBT Group|