cmsisdap: Fix block transfer response parsing

[Dirbaio]

Fixes a regression when flashing the rp2040 inrdocued in #745. Logs: https://gist.github.com/Dirbaio/7c7bc3fc7023679b9f36aa4c627a7f40

@Tiwalun was there a particular reason to change it to use the buffer len? Does changing it back break something?

[twelho]

I'll confirm that this fixes all the CLI tools and cargo flash resulting in that exact same slice length mismatch panic with an ATSAMD51G19A probed by an ST-Link V2 clone running dap42. cargo flash was hitting various timeouts (likely due to countless retries, with the debug logs filling up with messages like Expected 14 responses, got 15 responses with data..), so I wasn't sure if the issue was with the probe or the code. Thank you so much for this patch, after a week of debugging and frustration the tools now seem to finally work without issues and I was able to successfully flash the chip.

[twelho]

The preceding calculation of num_transfers and associated Expected {} responses, got {} responses with data.. debug print could also be removed now as they're left unused after this change.

[Tiwalun]

The transfer count doesn't work unfortunately, because only reads have a response. So the transfer count does not indicate how much data we have to read. It might make sense to use it as an upper limit.

The best solution would probably be to store the number of reads somewhere.

[Dirbaio]

Okay, this should be correct now, if I understood the problem correctly:

• For reads, read exactly transfer_count words from the payload.
• For writes, read nothing from the payload.

Again, tested working flashing RP2040 with DapperMime probe firmware.

[Yatekii]

bors r+

[bors]

Build succeeded:

• Check (macos-latest)
• Check (ubuntu-latest)
• Check (windows-latest)
• Rustfmt
• Test Suite (ubuntu-latest)
• Test Suite (windows-latest)