For CAN transport the slave response EV_CMD_PENDING is ignored

[still-learnin]

When I issue the PROGRAM_START command the slave responds with EV_CMD_PENDING at 0.3ms intervals for approximately 3s. My understanding is that the master should restart the time-out detection on this event. However it seems the master is ignoring these responses and I then see a timeout.

Is this functionality implemented?

Sometimes the master also seems to send the SYNCH command after approximately 1.2ms, but I have not investigated that scenario fully. Either way a SYNCH or timeout seems to be the wrong behaviour.

[christoph2]

Well, sending SYNCH and retrying is basically the correct response to timeouts.
You're right, EV_CMD_PENDING should reset the timeout counter. But XCP events were simply ignored, as you suspected. This is fixed now, I hope it works for you.

P.S.: Programming via (py)XCP sounds quite interesting, could you tell me more what you're doing?
Good ideas, how an high-level flashing interface could look like, are highly welcome 😃
I'm asking, because my asamint project will also include flashing/programming stuff.

[still-learnin]

I have tested this and it all looks good (certainly more elegant than the kludge I implemented this morning just to see if it made my programming sequence more reliable. Thank you.

I don't know if this is of much help but:

I am/have been extending an existing automated test system for a CAN based ECU to support XCP over CAN for mainly reading and writing characteristics and programming the ECU. I think a common high level interface for programming is quite difficult to pin down since the specific sequence and implementation is left very open in the standard. In my case the bootloader (or 'flash kernel' as XCP seems to refer to it) is already on the ECU so really it is a matter of downloading the program and then issuing the reset. In-fact my implementation to interface to the master program methods is based nearly 100% on your 'push' convenience function (apart from the code at the start and end of the method to do setup and then reset. I have attached this code in 'flash.txt'.

Currently I will need to fork the project - unless you feel so inclined to include the changes in attached 'updated_methods.txt' (although I will need to fork anyway for the issue [#85] that I raised). Basically the changes are to the 'program' and 'program_next' methods to effectively mirror the 'download' and 'download_next' methods. Also the specification indicates a response from PROGRAM_RESET is optional so this should probably be parameterized (although I fixed it as no response), as it will be application dependent, although in most embedded systems I suspect guaranteeing to get a response is highly unlikely.
flash.txt
updated_methods.txt