push and _block_downloader convenience method do not wait for response

[still-learnin]

I have started using the push function to write to longer array characteristics and have discovered that both the push and _block_downloader methods always use the 'download' method with the blockModeLength != None and the 'download_next, with last == False. This means that the transport layer is not waiting for the response at the end of the block. This is true even for short data blocks that can be sent in a single download. I think both methods need a last flag and to be used in much the same way that I use the program methods as I discussed in Issue #88 (flash.txt), in answer to your question about programming via XCP.

[christoph2]

What is currently missing: Common downloading functions (work in progress).
program and programNext are now implemented as you've suggested,
response from PROGRAM_RESET is now optional, so your functions from flash.txt may (hopefully) work.

[still-learnin]

I have tested the program functions but there is an issue with the optional response on program reset. Error message is:

line 166, in _request_internal
pid = types.Response.parse(xcpPDU).type
UnboundLocalError: local variable 'xcpPDU' referenced before assignment

I have not investigated further in-case you see it is something obvious.

[christoph2]

OK, fixed

[christoph2]

Halfway done:

• _block_downloader() is now reusable.
• push() now has an address parameter, no need to separately call setMta() anymore, but this is code-breaking!

[still-learnin]

I have just tried to use the flash_program convenience method. I think you have probably interpreted the min_st parameter incorrectly. It is meant to be in units of 100us. The reported min_st of the device is 5 and I am currently seeing a 5s gap between each program_next command. Estimated time to complete the download is 16hours:). In-fact I had interpreted it in ms so it was a good exercise to go and check the spec. since this will speed up my programming time.

Will you be implementing the callback? I see you have included the parameter. I use it not just to indicate progress but in some cases I am planning to trigger brownouts etc., at x% complete, to check that the ECU recovers from such events.

[still-learnin]

I have tested your latest release and this all works well now thank you.