probe: cmsis-dap: set retry count to max value by default #1505
Conversation
This patch sets the retry count for DAP transfers to the highest value by default. This is needed since flash erase will stall a read operation for a long time on the nRF9160. Signed-off-by: Maximilian Deubel <[email protected]>
|
I think it should be no problem to have a very high retry value. Since the target still has to send ACK_WAIT responses, we still return failure on broken connections. |
|
👋🏽 Thanks for the patch! Do you happen to know the number of retries that are required on average? Mostly just curious, but it would also be good to know how close it is to the maximum. If it's too close, then pyocd should probably be performing its own retries in addition to the probe (that just hasn't been necessary in any other cases). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Yes, I agree that it shouldn't be a problem. But actually, the retry count should be configurable by the user and target. (Hmm, I'll add a "minimum required retry count" to my [Open-]CMSIS-Pack wish list.) |
That of course depends on the bus speed, but I saw 6232 retries on a 1MHz SWD connection and that was not even the slowest operation. |
|
Ok, thanks. So with 6232 at 1 MHz, it should be safe to go up to somewhat faster than 10 MHz using a retry count of 64k. Probably alright for now. And one can always use a slower SWD clock if a chip erase is needed. |
|
fyi: this change happened to fix Puya MCU flash programming which also seems to take a long time to erase. Got timeout errors before. |
3 participants
This patch sets the retry count for DAP transfers to the highest value by default.
This is needed since flash erase will stall a read operation for a long time on the nRF9160.