Closed emard closed 9 years ago
Looks like bad CRC received is the vaild CRC but from old block, so it looks like new block is still in linux transmit buffer and haven't been send to f32c
that explains why delay fixes it but some waiting for tx to complete in ujprog should be the solution
latest patch in ujprog with tcdrain(com_port) fixes above issue, tested in linux-64bit
On Tue, 24 Nov 2015 06:45:37 -0800 emard notifications@github.com wrote:
latest patch in ujprog with tcdrain(com_port) fixes above issue, tested in linux-64bit
Uuuu pojma nisam imao da postoji tcdrain()... To je to, build prolazi cak i na OSX-u, budem sutra to tam i probao.
Meni je guzva do 8:00, jel ti OK da se nadjemo oko 8:20? Nadam se da cu uspjet probit se do Kruga, ak zapnem zovem na mob.
Marko
On Tue, Nov 24, 2015 at 06:53:36AM -0800, Marko Zec wrote:
On Tue, 24 Nov 2015 06:45:37 -0800 emard notifications@github.com wrote:
latest patch in ujprog with tcdrain(com_port) fixes above issue, tested in linux-64bit
Uuuu pojma nisam imao da postoji tcdrain()... To je to, build prolazi cak i na OSX-u, budem sutra to tam i probao.
;) ko da sam ja znao da postoji ali probao sam stvari fsync pa nije išlo!
Super budeš to compajlirao i releasaj na nxlab a ja budem to spakirao u json
Meni je guzva do 8:00, jel ti OK da se nadjemo oko 8:20? Nadam se da cu uspjet probit se do Kruga, ak zapnem zovem na mob.
Super 8:20 to je standardno vrijeme!! Javi mi na 099
CRC retry is fixed but still binary upload will sometimes fail.
Manifests at first with CRC error, block sending is retried, CRC is OK but uploaded code doesn't work.
ujprog is patched to use -D option to insert a pause after sending binary
block, before issuing 0x81 command to read checksum
It is not clear is it f32c bootloader problem or some usbserial or kernel serial issue
So when binary uploads fail, try to slow it down a bit: ujprog -D100