Well, had enough for tonight. Wireshark shows ISO IN requests but neither the datainstage or SOF handlers are being called so I need to work out why. That’s for another night. I have a USBD_LL_Transmit() in there with my old trusty buffer with deadbeef in ascii so it’s easily searchable within the packet payload in wireshark.
I suspect this may require a dma transmit poll call for n the main loop as I have the USB DMA disabled at the moment. Doh!
Host only sends IN tokens for inbound data transfers so SOF interrupts should not occur.
Quick question: did you try using MPU regions to manage the caching policies for memory segments containing USB DMA access locations?
I was thinking that defining the memory regions for USB DMA inside an area where the MPU has been configured with a corresponding region setup to not data cache and not to write buffer the DMA areas. Naturally the same with the other areas of the memory map. This would, then allow the CPU to operate with data cache, instruction cache and buffer except for the USB region itself. However as the USB has it's own DMA that should work... it's about the only option I see that has not been tried (most people decide that removing the caching outright saves development time).
https://www.st.com/resource/en/appl...ion-unit-in-stm32-mcus-stmicroelectronics.pdf
Yes, I have tried them and actually they are in use currently to have dma buffers in SRAM1&2. But they have not helped in USB OTG DMA issue.
So I now have about a week of play time 😀 (the mrs is working and I'm now on vacation).
The first task is to understand from principles the USB IN and OUT mechanisms and the STM32 firmware handling for these. The reason is simply that the STM32 USB firmware should support USB 2.0 HighSpeed but as the USB Audio 1.0 component simply has no understanding of how to handle SOF micro-frames, it will need review to ensure it's operating correctly.
At the same time I want to understand the data transfer mechanisms for flow control, specifically for the OUT, which I will need later. If I have that written down it will make implementing something easier at a later date.
Currently the questions I have are:
a) How is returned information associated with a transaction given there's no transaction identifier. For example, it is feasible to have 3 IN transactions in a frame yet the data returned for the IN has no linking identifier, hence I assume the data for each transaction is handled as a DATA2/1/0 followed by the next data transaction DATA2/1/0 followed by the final transaction data. That implied index in each frame then allows the host to route to the right transaction.
The STM USB code provides a IN stage (ie a transaction phase) which is the way that the USB driver indicates the IN has been received. For HS that will be every 125uS with each of the 8 sub-frames sharing the same 1mS frame number.
The STM code seems to provide only the buffer to upload to the FIFO for that IN response. So I have an unanswered question about how the existing code copes with multiple transactions (not so much of an issue with IN but it will be an issue for OUT as the STM code seems to replicate the same mechanism for OUT). There is a gap and I'm attempting to understand if this is a gap in my knowledge of the STM code or a gap in the STM code itself.
The first task is to understand from principles the USB IN and OUT mechanisms and the STM32 firmware handling for these. The reason is simply that the STM32 USB firmware should support USB 2.0 HighSpeed but as the USB Audio 1.0 component simply has no understanding of how to handle SOF micro-frames, it will need review to ensure it's operating correctly.
At the same time I want to understand the data transfer mechanisms for flow control, specifically for the OUT, which I will need later. If I have that written down it will make implementing something easier at a later date.
Currently the questions I have are:
a) How is returned information associated with a transaction given there's no transaction identifier. For example, it is feasible to have 3 IN transactions in a frame yet the data returned for the IN has no linking identifier, hence I assume the data for each transaction is handled as a DATA2/1/0 followed by the next data transaction DATA2/1/0 followed by the final transaction data. That implied index in each frame then allows the host to route to the right transaction.
The STM USB code provides a IN stage (ie a transaction phase) which is the way that the USB driver indicates the IN has been received. For HS that will be every 125uS with each of the 8 sub-frames sharing the same 1mS frame number.
The STM code seems to provide only the buffer to upload to the FIFO for that IN response. So I have an unanswered question about how the existing code copes with multiple transactions (not so much of an issue with IN but it will be an issue for OUT as the STM code seems to replicate the same mechanism for OUT). There is a gap and I'm attempting to understand if this is a gap in my knowledge of the STM code or a gap in the STM code itself.
Just to clarify, what do you mean by "STM32 firmware", "STM code" and "USB Audio 1.0 component"?
The stm32 code (they term firmware) that is provided as the HAL.
I don’t use the USBaudio 1.0 code without modifications.
I spent this morning looking further at this and it’s staring to become clearer.
The HAL PCD is not really a firmware but just a thin layer on top of the actual USB OTG firmware (by Synopsys). Source code for that firmware is not available. STM32F7 USB OTG HS supports USB HS speeds.
I do not follow your question regarding token and data packets in relation to transactions. All that should be hidden from the developer within HAL and USB OTG firmware.
I do not follow your question regarding token and data packets in relation to transactions. All that should be hidden from the developer within HAL and USB OTG firmware.
You mean code, generated by Cube or which was found in examples?
Why not to try to explore the code from other manufacturers? As I remember, XMOS, Cmedia, ComTrue provides the source codes.
There’s a couple of reasons:
1. Using the STM cube + frameworks means the code can easily be updated to support new generations of chips as they come out. This also makes for more interested users.
2. License/legal - having a MIT license/STM for their portions makes it easy from legal and liability perspective.
The code is separate but offers a hooks into the existing cube generated code/frameworks.
This might be useful, if it provides the code for USB HS UAC2 operation. But as far as I know, only USB FS UAC1 is currently supported.
Correct.
However it's possible to replace the UAC1 with a modified UAC2 version (there's some gotchas but most is possible).
It doesn't help that both the Mrs and I went down with a stinking cold last night.. so I'm trying to design with about 3 hours of sleep, a thick head, a cough and aches..
The UAC1 code provided by STM Cube is just an example. STM32 MCUs are general purpose MCUs rather than audio-targeted such as XMOS so source code examples are meant to be just examples not working applications. I would not expect STM Cube examples to support UAC2 HS in the near future.