Bumped to ver21.11.3: https://github.com/trheinfels/ChibiOS/t ... provements
Also figured out that the locking issues from the last post were on my side. Austin's patch was correct about that to begin with!
Search found 10 matches
- Sun Mar 23, 2025 1:35 pm
- Forum: Development and Feedback
- Topic: USB Driver "Deferred" Control Transfers
- Replies: 5
- Views: 39505
- Sun Aug 25, 2024 8:29 am
- Forum: Development and Feedback
- Topic: USB Driver "Deferred" Control Transfers
- Replies: 5
- Views: 39505
Re: USB Driver "Deferred" Control Transfers
Alright, seems like I didn't test it with system state debug
Austin's patch separates the actual transfer code from the ISR context in order to reuse it when performing the deferred transfer from thread level. The resulting I-class function _usb_ep0transferI did contain locks itself, though. Fix ...
Austin's patch separates the actual transfer code from the ISR context in order to reuse it when performing the deferred transfer from thread level. The resulting I-class function _usb_ep0transferI did contain locks itself, though. Fix ...
- Thu Aug 15, 2024 8:03 am
- Forum: Development and Feedback
- Topic: USB Driver "Deferred" Control Transfers
- Replies: 5
- Views: 39505
Re: USB Driver "Deferred" Control Transfers
Hey you two,
I know this is an old thread, but I think having means to defer control transfers to threads would greatly improve the USB driver. Think of flash interactions (e.g., USB-DFU), which you really wouldn't want to do (and which you can't do using EFL driver) inside an ISR context.
@Austin ...
I know this is an old thread, but I think having means to defer control transfers to threads would greatly improve the USB driver. Think of flash interactions (e.g., USB-DFU), which you really wouldn't want to do (and which you can't do using EFL driver) inside an ISR context.
@Austin ...
- Wed May 31, 2023 1:53 pm
- Forum: Bug Reports
- Topic: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
- Replies: 6
- Views: 6435
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
- Sun May 28, 2023 10:01 am
- Forum: Bug Reports
- Topic: hal_usb: Zero-Length Packets for Control IN Transfers
- Replies: 3
- Views: 4762
Re: hal_usb: Zero-Length Packets for Control IN Transfers
Hi Giovanni,
sorry, I didn't find the time lately.
The peripherals (at least STM32L1) handle ZLPs just like any other packet: Setting the packet size to zero and marking the endpoint as valid will yield a ZLP at least in the bulk and control cases. This, however, has to be done by the driver. The ...
sorry, I didn't find the time lately.
The peripherals (at least STM32L1) handle ZLPs just like any other packet: Setting the packet size to zero and marking the endpoint as valid will yield a ZLP at least in the bulk and control cases. This, however, has to be done by the driver. The ...
- Thu May 18, 2023 12:16 pm
- Forum: Bug Reports
- Topic: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
- Replies: 6
- Views: 6435
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
- Thu May 18, 2023 12:14 pm
- Forum: Bug Reports
- Topic: hal_usb: Zero-Length Packets for Control IN Transfers
- Replies: 3
- Views: 4762
hal_usb: Zero-Length Packets for Control IN Transfers
Hi everybody,
I stumbled across another piece of the USB driver: for implementing a DFU function (and potentially any other control IN transfer), the device needs to send all data except for the last bytes as packets of the requested size. The host detects the end of the data stream when a short ...
I stumbled across another piece of the USB driver: for implementing a DFU function (and potentially any other control IN transfer), the device needs to send all data except for the last bytes as packets of the requested size. The host detects the end of the data stream when a short ...
- Sun Apr 09, 2023 10:01 am
- Forum: Bug Reports
- Topic: STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
- Replies: 6
- Views: 6435
STM32 USBv1: Off-by-one in NUM_BLOCK for OUT transfers of sizes >62 Bytes
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 ...
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 ...
- Wed Apr 13, 2022 5:24 pm
- Forum: Bug Reports
- Topic: STM32L1 (USBv1): Wrong DTOG_RX interpretation for isochronous transfers?
- Replies: 2
- Views: 4537
STM32L1 (USBv1): Wrong DTOG_RX interpretation for isochronous transfers?
Hi,
I'm currently implementing an isochronous data stream using UAC2 in asynch mode on an STM32L1 controller. To match the data rates, every once in a while an additional sample is transferred over the bus and this is where I get data corruption. Since I successfully ran the code on an STM32F4 ...
I'm currently implementing an isochronous data stream using UAC2 in asynch mode on an STM32L1 controller. To match the data rates, every once in a while an additional sample is transferred over the bus and this is where I get data corruption. Since I successfully ran the code on an STM32F4 ...
- Thu Nov 26, 2020 10:59 pm
- Forum: Bug Reports
- Topic: STM32F411xC/E: Wrong entries in PLLI2SCFGR
- Replies: 2
- Views: 13848
STM32F411xC/E: Wrong entries in PLLI2SCFGR
Hi,
the current LLD implementation for the STM32F4 family does not support the I2S PLL on the STM32F411xC/E (and presumably others).
- ChibiOS version
20.3.2 (as of the tag ver20.3.2 on the github mirror)
- Compiler
gcc version 10.2.0 (Arch Repository)
- Platform and board
STM32F411VET6 on ...
the current LLD implementation for the STM32F4 family does not support the I2S PLL on the STM32F411xC/E (and presumably others).
- ChibiOS version
20.3.2 (as of the tag ver20.3.2 on the github mirror)
- Compiler
gcc version 10.2.0 (Arch Repository)
- Platform and board
STM32F411VET6 on ...