Code:
Oct 15 16:22:46 raspberrypi kernel: [25675.658584] usb 1-1.2: new high-speed USB device number 56 using xhci_hcd
Oct 15 16:22:46 raspberrypi kernel: [25675.789693] usb 1-1.2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
Oct 15 16:22:46 raspberrypi kernel: [25675.789724] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 15 16:22:46 raspberrypi kernel: [25675.789745] usb 1-1.2: Product: DIY USB Audio 2.0 Class
Oct 15 16:22:46 raspberrypi kernel: [25675.789762] usb 1-1.2: Manufacturer: Nick's DIY Audio
Oct 15 16:22:46 raspberrypi kernel: [25675.789779] usb 1-1.2: SerialNumber:
Oct 15 16:22:46 raspberrypi kernel: [25675.795850] usb 1-1.2: invalid uac2 rates
Oct 15 16:22:46 raspberrypi kernel: [25675.795879] usb 1-1.2: invalid uac2 rates
Oct 15 16:22:46 raspberrypi kernel: [25675.795894] usb 1-1.2: invalid uac2 rates
Oct 15 16:22:46 raspberrypi kernel: [25675.795909] usb 1-1.2: invalid uac2 rates
Oct 15 16:22:46 raspberrypi kernel: [25675.795924] usb 1-1.2: invalid uac2 ratesSo we're getting there - I suspect I need to reverse the 192KHz sample rate.. byte ordering..
Nope not byte ordering. I can see through the SWV connection to the Mac running the IDE, the path of the code (I've got tracing printfs setup). I can see it's requesting a get frequency sample rate so I suspect my response is not being returned ... Wireshark time..
Last edited:
So using the command line Wireshark "tshark" with usbmonitor providing interface evesdropping for the RPi4:
This looks like 192000 in 0x0002ee00 - this seems to be the only packet with 20 ee but this looks messed up... off to investigate 🙂
Code:
0000 00 9f de c3 00 00 00 00 53 02 00 43 01 00 00 00 ........S..C....
0010 ac da 4a 63 00 00 00 00 ee 02 0d 00 8d ff ff ff ..Jc............
0020 00 00 00 00 00 00 00 00 01 0b 00 00 01 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................This looks like 192000 in 0x0002ee00 - this seems to be the only packet with 20 ee but this looks messed up... off to investigate 🙂
Wireshark GUI (either online or offline analyzing tshark dumps) can decode lots of USB data formats.
For kicks I decided to use 0xdeadbeef as the frequency to see if that packet was actually frequency.. I don't think it is..
However 0xdeadbeef resulted in this:
Hmm...
Well it seems 0xdeadbeef is a valid frequency for UAC2 lol.
I'm trying to find the way to setup tshark to decode usb. In theory "tshark -d . " shows the decodings available but the usb.protocol==x,y etc should be possible but I can't work out the command line format.
I suspect my packing of the response is incorrect - deadbeef doesn't appear in the byte dump of the packets.
However 0xdeadbeef resulted in this:
Code:
Oct 15 17:26:26 raspberrypi kernel: [29495.841577] usb 1-1.2: USB disconnect, device number 69
Oct 15 17:26:51 raspberrypi kernel: [29520.542944] usb 1-1.2: new high-speed USB device number 70 using xhci_hcd
Oct 15 17:26:51 raspberrypi kernel: [29520.674066] usb 1-1.2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
Oct 15 17:26:51 raspberrypi kernel: [29520.674098] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 15 17:26:51 raspberrypi kernel: [29520.674120] usb 1-1.2: Product: DIY USB Audio 2.0 Class
Oct 15 17:26:51 raspberrypi kernel: [29520.674140] usb 1-1.2: Manufacturer: Nick's DIY Audio
Oct 15 17:26:51 raspberrypi kernel: [29520.674157] usb 1-1.2: SerialNumber:Hmm...
Code:
pi@raspberrypi:/var/log $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 4: Class [DIY USB Audio 2.0 Class], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0Well it seems 0xdeadbeef is a valid frequency for UAC2 lol.
I'm trying to find the way to setup tshark to decode usb. In theory "tshark -d . " shows the decodings available but the usb.protocol==x,y etc should be possible but I can't work out the command line format.
I suspect my packing of the response is incorrect - deadbeef doesn't appear in the byte dump of the packets.
Last edited:
Why not opening the tshark dump in wireshark GUI?
I linked the f_uac2 source which generates the rate USB reply.
I linked the f_uac2 source which generates the rate USB reply.
I'll need to re-read the audio section again. I can see range has triplets of 32bytes and precsion=0 for example but the only example they have is bCUR as 1 byte, I've put in 4 bytes but as you've pointed out - that needs changing (hence why I don't see the right packet).
I'm using the RPI image without a desktop and without a display. I could reinstall but then I have to run a Remote Desktop etc and I never got on with getting that running in linux (I've done it a few times with varying success).
Well giving up for the night. Whatever I give it - it seems to take a random 4 bytes;
a) the memory I've even tried mallocing so the memory is permanent (leaking) and off the stack
b) the memory is aligned to 4 byte boundary..
c) packed with a full control request header
d) without header
The system is using DMA, but whatever I've put to send.. it comes out random. Wire shark is showing 4 byte request, a 4 byte response but 4 bytes random.
So unless the DMA isn't operating.. or there's a corruption on the DMA transfers list..
I'll trace through when I have more patience.
a) the memory I've even tried mallocing so the memory is permanent (leaking) and off the stack
b) the memory is aligned to 4 byte boundary..
c) packed with a full control request header
d) without header
The system is using DMA, but whatever I've put to send.. it comes out random. Wire shark is showing 4 byte request, a 4 byte response but 4 bytes random.
So unless the DMA isn't operating.. or there's a corruption on the DMA transfers list..
I'll trace through when I have more patience.
I did notice that the IDE doesn't provide the option at the pin assignment editor to use DMA with OTG HS, even though the comments indicate that HS and DMA should be used for the best performance!
The two internal DMA engines support a set of mappings (ie the GPIO, UART etc) for the peripheral but the HS OTD DMA is a completely different (and dedicated) system. I'm currently checking the reference documentation.
There is a ARM cortex bug too which impacts DMA transfers with memory areas covered by the data cache of the ARM.
I have not seen any performance issues with USB OTG DMA disabled. IME using DMA with SAI is more important for performance.
Just reading through the reference doc.
The STM driver simply decides (at a low level) if it will use the DMA registers, they're correct as per the ref doc:
The driver defines the registers as a structure with an __IO define I assume that defines them as volatile and perhaps marks them as aligned too - that define is in the core_m7 include from ARM. That would be enough, as long as there's no multicore or data caching (one would hope the DMA registers sit in a non-D-cached through area..
I'll switch off DMA for now and see how that works out..
Simply switching off DMA for HS results in the correct value provided:
So this is a DMA issue and I assume a D-cache over area..
Sure enough - no issues with UAC2 clock rates now on Linux.. stick freezes the Mac 🙁
So this is a DMA issue and I assume a D-cache over area..
Sure enough - no issues with UAC2 clock rates now on Linux.. stick freezes the Mac 🙁
Last edited:
Fine and nice to see I'm not alone 🙂
In HAL the address of the buffer you pass to USBD_LL_Transmit will be set as dma address if dma is enabled. Even aligning this buffer to 4-bytes does not help so I assume things go wrong somewhere within the Synopsys OTG controller.
In HAL the address of the buffer you pass to USBD_LL_Transmit will be set as dma address if dma is enabled. Even aligning this buffer to 4-bytes does not help so I assume things go wrong somewhere within the Synopsys OTG controller.
I’m wondering if __DSB() cache control operations etc are needed. Basically ensure the data is written out into main memory before the dma is initiated.
I gave the __DSB, along with __DSM and __DISM a try but unfortunately it doesn't make difference. I suspect more work is required to verify that.
With the DMA disabled, it still works and now I had a look at the device and rate it understands is available:
So that looks good.. so far.
With the DMA disabled, it still works and now I had a look at the device and rate it understands is available:
So that looks good.. so far.
For reference if I come back to this..
The reference manual: https://www.st.com/resource/en/refe...ed-armbased-32bit-mcus-stmicroelectronics.pdf
ST point on the DMA D-cache issue: https://community.st.com/s/article/how-to-enable-dma-in-usb-with-stm32h7-devices
The next step is the i2s. This seems to have generated correctly, It's initialised but there's no external clock so it sits idle currently. So it's possibly time to build the metal case, drill the holes etc. This will then provide the hardware required to setup the i2s with proper signalling. That should the drive the interrupt, dma, and ring buffer. Once in the case all the external connections are either banana, BNC, XLR or USB. So it will make things neat and tidy. I can then use the RPI using ALSA arecord capture in the interim.
This is the case: https://www.mouser.co.uk/ProductDetail/Hammond-Manufacturing/1402H?qs=zAx27f%2BWkoGxM/EZQs7NoA== which seems really usefully able to break in 1/2 to fit or play around inside the case. It should then fit under the scope.
I still need to work out why the Mac freezes - perhaps an ssh should then find out what is causing the CPU load and then into fault finding.
The reference manual: https://www.st.com/resource/en/refe...ed-armbased-32bit-mcus-stmicroelectronics.pdf
ST point on the DMA D-cache issue: https://community.st.com/s/article/how-to-enable-dma-in-usb-with-stm32h7-devices
The next step is the i2s. This seems to have generated correctly, It's initialised but there's no external clock so it sits idle currently. So it's possibly time to build the metal case, drill the holes etc. This will then provide the hardware required to setup the i2s with proper signalling. That should the drive the interrupt, dma, and ring buffer. Once in the case all the external connections are either banana, BNC, XLR or USB. So it will make things neat and tidy. I can then use the RPI using ALSA arecord capture in the interim.
This is the case: https://www.mouser.co.uk/ProductDetail/Hammond-Manufacturing/1402H?qs=zAx27f%2BWkoGxM/EZQs7NoA== which seems really usefully able to break in 1/2 to fit or play around inside the case. It should then fit under the scope.
I still need to work out why the Mac freezes - perhaps an ssh should then find out what is causing the CPU load and then into fault finding.
Last edited: