Luckily I think I possibly found the root cause. Which is an buffer oveflow caused by pio_usb_ll_encode_tx_data() (introduced by https://github.com/sekigon-gonnoc/Pico-PIO-USB/commit/7ce6e4a5caf43275853ab22f213ad094825735be). The function will overflow 1 byte for pre-encoded PID (ack/nak/stall/pre). This can be easily tested with pure C program compiled and run on x86 PC with following main.c
00 01 02 03 04 05 06 07
dd df 5d 7f 25 55 aa aa
dd df 5f d7 25 55 aa aa
dd df 55 77 25 55 aa aa
dd df 7f f7 25 55 aa aa
all messages is memset with 0xaa and we can clearly see that [5] is written. I guess the reason that we can get away with non -Os is
compiler give us 8 bytes for array of 5
and/or even if they give 5 bytes, the latter call will correct the former one by rewrite the message. As long as there is 1 byte padding after pre_encoded, we are all good.
Although I have no clues how to fix this, increase 1 byte may not ideal, since this function is also called in run time. thus this PR is only an placeholder for discussion. @sekigon-gonnoc definitely know the correct fix.
I have been trying to troubleshoot issue for
0.6.0
with-Os
. TBH, it is rabbit hole for me since I am not familliar with pio at all.Luckily I think I possibly found the root cause. Which is an buffer oveflow caused by pio_usb_ll_encode_tx_data() (introduced by https://github.com/sekigon-gonnoc/Pico-PIO-USB/commit/7ce6e4a5caf43275853ab22f213ad094825735be). The function will overflow 1 byte for pre-encoded PID (ack/nak/stall/pre). This can be easily tested with pure C program compiled and run on x86 PC with following main.c
The output is
all messages is memset with 0xaa and we can clearly see that [5] is written. I guess the reason that we can get away with non -Os is
Although I have no clues how to fix this, increase 1 byte may not ideal, since this function is also called in run time. thus this PR is only an placeholder for discussion. @sekigon-gonnoc definitely know the correct fix.
@ladyada