Hi everybody,
I had some issues with a USB bulk function on an STM32L1 controller (basically an echo for now) in that replied garbage. I could narrow it down to the USB peripheral wreaking havoc in my IN region of PMA. Given the datasheet [1, pp. 615/3018 - 616/3018, especially table 107], this happens due to NUM_BLOCK being one too large in the USBv1 implementation: For BL_SIZE=0 this field is 1-indexed while for BL_SIZE=1 it starts with 0 (Intuitive design, isn't it? ).
With the following change I got rid of the problem:
os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:643
nblocks = (((((epcp->out_maxsize - 1U) | 0x1FU) + 1U) / 32U) << 10) |
should read
nblocks = ((((epcp->out_maxsize - 1U) | 0x1FU) / 32U) << 10) |
,i.e., round down instead of up for packet sizes >62 bytes.
I'm pretty certain about this, however I wonder why nobody else stumbled across this issue. Anyway, here is the remaining information:
- ChibiOS version
21.11.1 (as of the tag ver21.11.1 on the github mirror)
- Compiler
gcc version 12.2.0 (Arch Repository)
newlib version 4.2.0.20211231-1
- Platform and board
STM32L151CBT6A on a custom board
- Nature of the problem / Failure Mode
Data is being corrupted in the PMA.
Cheers
Tim
[1] ST: Reference Manual RM0038. Revision 17: https://www.st.com/resource/en/referenc ... ronics.pdf
STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes Topic is solved
-
- Posts: 7
- Joined: Mon Sep 07, 2020 2:00 pm
- Has thanked: 2 times
- Been thanked: 2 times
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
Hi,
Thanks, will look into this.
Giovanni
Thanks, will look into this.
Giovanni
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes Topic is solved
Hi,
The same problem (and a very old one...) was present also in the USBv2 driver, fixed both, please give it a try.
Giovanni
The same problem (and a very old one...) was present also in the USBv2 driver, fixed both, please give it a try.
Giovanni
-
- Posts: 7
- Joined: Mon Sep 07, 2020 2:00 pm
- Has thanked: 2 times
- Been thanked: 2 times
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
Hi Giovanni,
thank you very much for the quick reply. I'll gladly test the revised driver if you can point me to the sources (the github mirror does not contain those changes).
Cheers
Tim
thank you very much for the quick reply. I'll gladly test the revised driver if you can point me to the sources (the github mirror does not contain those changes).
Cheers
Tim
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
Hi,
The official repository is the svn available here: https://sourceforge.net/projects/chibios/
Git mirrors are updated from that one periodically.
Giovanni
The official repository is the svn available here: https://sourceforge.net/projects/chibios/
Git mirrors are updated from that one periodically.
Giovanni
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
Hi,
Can this be closed?
Giovanni
Can this be closed?
Giovanni
-
- Posts: 7
- Joined: Mon Sep 07, 2020 2:00 pm
- Has thanked: 2 times
- Been thanked: 2 times
Re: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
Hi Giovanni,
sorry for the late reply, had to prepare the hardware. Works like expected as of the current trunk (r16277). Thanks for fixing it!
Best Regards,
Tim
sorry for the late reply, had to prepare the hardware. Works like expected as of the current trunk (r16277). Thanks for fixing it!
Best Regards,
Tim
Who is online
Users browsing this forum: No registered users and 30 guests