Wait after disposing device to ensure SerialPort is released

[MicBoucinha]

As per description on #99 , this PR moves the wait after the initial device Reset using block. This prevents errors when opening the SerialPort afterwards since it gives enough time for the previous connection to be closed.

[glopesdev]

@MicBoucinha this is great, thanks, this error had been annoyingly persistent. I am not entirely happy that the timing dependency is there, but I guess it is currently unavoidable, and inherent to the fact that SerialTransport disposal is asynchronous:

harp/src/Bonsai.Harp/SerialTransport.cs

Line 70 in e7b5e07

taskCancellation.Cancel();

The current behaviour was introduced in #66 which was important both to ensure mono/linux compatibility and to resolve other issues with the synchronous implementation. I never realized at the time that it broke the reliability of firmware upload.

I will look into whether there are any recommendations for making some kind of "awaitable" dispose.

[glopesdev]

Indeed, the SerialTransport class should really implement IAsyncDisposable to allow the original implementation to work unchanged (via the async using pattern).

Sadly, implementing this interface is not possible in net472 without adding extra packages, since it depends on ValueTask.

In principle this is not really a problem since the current bootstrapper already pulls in all of these, but I still have to evaluate whether this will bring any possibility of impacting scripting extensions, and a few other edge cases.

[glopesdev]

@MicBoucinha if you have the chance to try out #104 it would be great to know if it resolves this issue without the need for a timer. We can worry about cleaning up the API later.

[MicBoucinha]

@glopesdev I tried the generated artifacts of #104 in the following ways:

• through my net8.0 application, calling Bootloader.UpdateFirmwareAsync method as it currently is done in harp-cli
• through bonsai 2.8.5

In both situations, I always get a "Access to COMX is denied" before the 30% progress mark.

However, I can confirm that at least in my application, when applying the wait time after the async using block, things are more consistent on every update. Before that, I needed to also slightly change the FlushDelayMilliseconds from the current 500ms to 700ms.

If you have any further suggestions for testing, please let me know.

Cheers!

[glopesdev]

@MicBoucinha thanks for trying it so quickly!

when applying the wait time after the async using block,

Do you mean here using the changes in this PR (#100) instead of the ones in #104?

Before that, I needed to also slightly change the FlushDelayMilliseconds from the current 500ms to 700ms.

If the answer to the above is no (i.e. the flush is still inside the await using block), were these changes made only in that flush block, or did you have to add an extra flush outside anyway?

things are more consistent on every update.

Do you still get errors occasionally? That would be unfortunate. In that case, can you confirm whether the changes in this PR #100 result in a 100% success rate?

Basically, I am trying to assess whether this depends only on serial port state on the Controller (PC) side, or whether it also depends on the state of the Device after resetting. If the latter, I agree perhaps it is best to simply increase the flush timer and avoid worrying about IAsyncDisposable for now, but would be good to know for sure and try to converge on a procedure resulting in at least ~99% success rate.

[glopesdev]

@MicBoucinha If it makes things easier to explain, feel free to review #104 with the changes you had to make to get a more reliable success rate.

[MicBoucinha]

Hi @glopesdev,

Do you mean here using the changes in this PR (#100) instead of the ones in #104?

I tried the changes on #104 and I was getting the "Access to COMX is denied" consistently. Before that, I was getting it most times but after trying 7-8 times, it would be able to open the SerialPort to upload the new firmware, which would do it just fine. With #104 though, I always get the error and even after trying more times, the error was always there. This in my application, which is easier for me to follow where it breaks. I've made a couple more tests and I want to correct that the error shows up after changing to the 30% mark, not before, as I previously said.

On Bonsai 2.8.5, the behavior with #104 is the same, but with extra issues. Bonsai shows the "Access to COMX is denied" error message box but after that it seems to continue the process and shows the uploading progress bar. The progress bar moves and when it reaches 100%, the progress bar window closes normally, but there was no firmware uploaded. This is also consistent in every test I did.

After that, what I did in my application (still using #104), I moved the two lines I did in this PR and kept the flush delay as 500ms (removing the delay from within the now async using block).

I cannot confirm that is 100% success rate in updating the firmware but close to 90%. On occasions I get a different error, on the next step. The error I get is "The device responded with an invalid response checksum.". This error does not happen very often though (once every 10-12 uploads).

Please let me know how can I further assist on this.

Cheers!

edited: missing "step" word.