dehanj
commented
10 months ago Been investigating this and found a few issues. I have ported this code and have a working copy in tkeyclient/load_app_multi_frame so will close this issue.
What i found. CH552 drops bytes, and that is what you saw when the transfer failed. I have a fix for it in this branch. It was most likely more prone to happen when sending multiple frames in parallel, compared to "ordinary" usage.
Some minor issues I found was that the nsent variable was not set to zero if the queue is full, hence offset is updated even if we don't transfer anything. Se this snipped from above, offset goes from 254 to 889 with just one transfer.
LoadAppData tx (frame len: 1+128):
00000000 53 05 13 05 55 e8 aa cf 37 a5 ca 84 13 05 b5 73 |S...U...7......s|
00000010 aa cd 37 f5 6e 3c 13 05 25 37 aa d3 37 05 95 fe |..7.n<..%7..7...|
00000020 13 05 b5 82 aa d1 37 f5 4f a5 13 05 a5 53 aa d7 |......7.O....S..|
00000030 37 35 1d 5f 13 05 15 6f aa d5 37 55 0e 51 13 05 |75._...o..7U.Q..|
00000040 f5 27 aa db 37 85 e6 ad 13 05 15 2d aa d9 37 75 |.'..7......-..7u|
00000050 05 9b 13 05 c5 88 aa df 37 75 3e 2b 13 05 f5 c1 |........7u>+....|
00000060 aa dd 37 e5 83 1f 13 05 b5 9a 23 22 a1 10 37 c5 |..7.......#"..7.|
00000070 41 fb 13 05 b5 d6 23 20 a1 10 37 d5 e0 5b 13 05 |A.....# ..7..[..|
00000080 95 |.|
QUEUE after send ID:2: [0 1 2] (nsent:127 offset:254 binlen:27656)
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0) (frame len: 1+4):
00000000 11 06 00 00 00 |.....|
QUEUE after recv: [1 2]
LoadAppData tx (frame len: 1+128):
00000000 73 05 08 6d f2 fd 15 e5 fd 13 45 15 00 e5 b7 13 |s..m......E.....|
00000010 fc 34 00 13 15 2c 00 4e 95 00 41 05 65 13 05 05 |.4...,.N..A.e...|
00000020 15 0a 95 13 06 00 08 81 45 97 60 00 00 e7 80 a0 |........E.`.....|
00000030 d5 01 45 83 a5 0d 08 f5 dd 83 a5 4d 08 33 06 ad |..E........M.3..|
00000040 00 05 05 23 00 b6 00 e3 16 85 fe 93 f5 84 01 01 |...#............|
00000050 45 e3 92 75 fb 13 d5 54 00 93 7c 35 00 05 65 13 |E..u...T..|5..e.|
00000060 05 05 0d 0a 95 13 06 00 08 81 45 97 60 00 00 e7 |..........E.`...|
00000070 80 80 d1 05 65 13 05 05 15 0a 95 03 45 05 00 7d |....e.......E..}|
00000080 15 |.|
QUEUE after send ID:3: [1 2 3] (nsent:127 offset:889 binlen:27656)
I've tried rewriting the LoadApp function to queue -- keep in flight -- multiple LoadAppData cmds, while reading the responses only when they come in. This should be possible since we have an RX FIFO of 512 bytes in hardware.
The idea is to keep the app continuously fed with data to process, instead of waiting for its responses (acks) for every frame of data. The goal being faster loading of the app.
There are two branches.
loadappdata-queueis a first attempt, which I think is flawed because (when the queue is full) it waits for and reads a response after each sending of cmd.The second attempt
loadappdata-queue-take-2always makes an attempt to read a response, but times out after some milliseconds if there is none. But both attempts fails in the same way. After a few cmds/responses, we get a response which has the wrong cmd code. Running towards QEMU works though. And setting thequeueLento 1 works for running towards hw.Output from running
loadappdata-queue-take-2: