Race condition/memory corruption on CH32V307
PoroCYon opened this issue · comments
Operating System
Linux
Board
CH32V307 (using both the SCDZ devboard and a custom board)
Firmware
Provided at https://github.com/PoroCYon/tinyusb-bug-repro --- both a CH32V307 version, and an RP2040 version which does functions correctly.
What happened ?
On the CH32V307, using DFU, the following effects may be observed:
- The data buffer received by the DFU functions is 64 bytes off (can be in either direction)
- This feels like a race condition thing, as it is very repeatable with
CFG_TUSB_DEBUG=2or ASAN enabled, while without it happens much more randomly
- This feels like a race condition thing, as it is very repeatable with
- Random bytes in the data buffer are corrupted (watch the CRC)
- Sometimes it hangs (due to a crash due to the memory corruption, I think)
- With payloads larger than 512 bytes, crashes seem to almost always happen.
How to reproduce ?
Compile and load the provided firmware onto the chip. Then run dfu-util -D payload.py. Watch how the data in the hexdump changes, the CRC changes (for hard to spot single-byte errors), and how sometimes, hangs/crashes occur.
Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)
This gist contains three log files:
log-vkart-rp2040.log: RP2040, working correctlylog-vkart-ch32v307.log: CH32V307, showing erratic behavior, withCFG_TUSB_DEBUG=0log-vkart-ch32v307.2.log: CH32V307, withCFG_TUSB_DEBUG=2, showing wrong but repeatable output
Screenshots
No response
I have checked existing issues, dicussion and documentation
- I confirm I have checked existing issues, dicussion and documentation.
(cc @gregdavill since he is the author of the driver/backend/port?)
#2392 indeed seems to fix the issues, thanks! (Should this issue be closed as a duplicate then?)
Glad it works, it can be closed once PR merged.