On 28/04/12 12:49, [email protected] wrote: >> This last bit is a bug that was fixed a couple days ago, can you try this >> with the latest from git? > solved > >> But in any case, the problem isn't in this, or the size of the >> re-enumeration timeout, but rather the fact that the driver doesn't appear >> to wait at all. It should log "fx2lafw: Waiting for device to reset." >> before >> waiting up to MAX_RENUM_DELAY (3 seconds), periodically checking. >> >> I don't see a path through the code that could cause this. After a >> firmware >> upload, the timestamp (ctx->fw_updated) is set, and it's always checked >> before the device is opened. > sr: GTV_TO_MSEC(ctx->fw_updated) = -122041897 > > You should check the GTV_TO_MSEC macro and use longlong when converting to > msecs on 32-bit (there is a reason why two longs are used for msec > accuracy ;-) ). > > Or check for != 0 instead of> 0. > > -- Martin Nice work guys. Thanks for working on this. I never would have had time to sort it out this week.
The GTV_TO_MSEC thing was a good catch. I never noticed the problem because I'm on amd64! I will delete the CMD_FW_GET_VERSION command soon, and I have some extra features coming. Joel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
