Hi JMF11, I understand the design in the following way:
one 48k family xtal (24.572) to generate:
24M for USB
44.1k family
48k family
with a specific configuration of main pll:
Above the conf for 48k family and right clokcing for USB
And the conf for 44.1 family
Code change PLLI2SM conf with a function call defined in USB_DEVICE/App//usbd_audio_if.c
The is a little bit of overclocking to achieve that, anyway this should'nt be a big deal for the target.
Two configs in usb descriptor, maybe one for standard PCM/I2S, the other for DoP/DSD?
one 48k family xtal (24.572) to generate:
24M for USB
44.1k family
48k family
with a specific configuration of main pll:
Above the conf for 48k family and right clokcing for USB
And the conf for 44.1 family
Code change PLLI2SM conf with a function call defined in USB_DEVICE/App//usbd_audio_if.c
The is a little bit of overclocking to achieve that, anyway this should'nt be a big deal for the target.
Two configs in usb descriptor, maybe one for standard PCM/I2S, the other for DoP/DSD?
Hello BriKs, I'm far from being an expert there, but it looks OK and aligned with the initial project configuration. The PLLI2S at 98.304MHz corresponds to 48k multiples. The code for the 44.1 kHz familly applies aslightly lower ratio.
I see nothing obvioulsy wrong here.
I don't see overclocking here the HSE clock is in the CPU Range. The I2S clock is for the peripheral and is a different thing. Again looks OK.
Have to check the "synch" part.
But I don't have the same hardware as you have, so I won't be able to test.
Thanks for the idea of the PCM/DoP idea for the configs.
I see nothing obvioulsy wrong here.
I don't see overclocking here the HSE clock is in the CPU Range. The I2S clock is for the peripheral and is a different thing. Again looks OK.
Have to check the "synch" part.
But I don't have the same hardware as you have, so I won't be able to test.
Thanks for the idea of the PCM/DoP idea for the configs.
Hi, almost finish assembly of pcba 
I have some solder shorts to fix, will do that soon with my customer binocular. Little afraid about soldering a es9038q2m with 0.4 pitch qfn style package but it looks good.
Become impatient to fire it and dive into openuac code to try fix 48k issue
Can share kicad files, pcb from jlcpcb, solder with stencil and solder paste, place by hand... long work but worth it I hope
I have some solder shorts to fix, will do that soon with my customer binocular. Little afraid about soldering a es9038q2m with 0.4 pitch qfn style package but it looks good.
Become impatient to fire it and dive into openuac code to try fix 48k issue
Can share kicad files, pcb from jlcpcb, solder with stencil and solder paste, place by hand... long work but worth it I hope
For I2S input on STM32 you can use this:
https://www.diyaudio.com/community/threads/uac2-i2s-input-on-stm32f723e-disco.393702/
https://www.diyaudio.com/community/threads/uac2-i2s-input-on-stm32f723e-disco.393702/
Yes, it is an updated version of code, but it doesn't work for me at all (no usb device found). It looks unfinished, so we have to wait for the final version.
But the previous vesion works great 44.1 - 384 kHz, DSD64/128.
This is how I solved the issues:
1. Add RCC->PLLCFGR |= 1 << 16; before LL_RCC_PLL_Enable(); (line 151 in original main.c file) after each code generation, due to CubeMX bug.
2. Comment tmp = CLAMP(tmp, -(1 << 16), (1 << 16)); (line 92 in original usbd_audio.c file). This will prevent buffer underflow issue for 48k family.
3. Set TIM3 ARR to 32, so modify TIM_InitStruct.Autoreload = 15; (line 338 in original main.c file) to TIM_InitStruct.Autoreload = 31; and define AUDIO_SYNC_CLK_DIV to 32, or to (TIM3->ARR + 1) if you want, to match TIM3 new ARR value. (line 47 in original usbd_audio.h file). This will solve buffer overflow issue for 384k.
4. Comment HAL_I2S_DMAStop(&AUDIO_I2S_SLAVE_HANDLE); (line 108 in original usbd_audio_if.c file). This will solve DSD stop stream issue.
But the previous vesion works great 44.1 - 384 kHz, DSD64/128.
This is how I solved the issues:
1. Add RCC->PLLCFGR |= 1 << 16; before LL_RCC_PLL_Enable(); (line 151 in original main.c file) after each code generation, due to CubeMX bug.
2. Comment tmp = CLAMP(tmp, -(1 << 16), (1 << 16)); (line 92 in original usbd_audio.c file). This will prevent buffer underflow issue for 48k family.
3. Set TIM3 ARR to 32, so modify TIM_InitStruct.Autoreload = 15; (line 338 in original main.c file) to TIM_InitStruct.Autoreload = 31; and define AUDIO_SYNC_CLK_DIV to 32, or to (TIM3->ARR + 1) if you want, to match TIM3 new ARR value. (line 47 in original usbd_audio.h file). This will solve buffer overflow issue for 384k.
4. Comment HAL_I2S_DMAStop(&AUDIO_I2S_SLAVE_HANDLE); (line 108 in original usbd_audio_if.c file). This will solve DSD stop stream issue.
Hi Thorp,
Thanks for sharing solution
I try to port the code for f446vet target and custom board, the code hang in usb iniit when MX_USB_OTG_HS_PCD_Init is called:
I check if USB330 24M is properly generated: OK, also check if audio clock is generated: OK.
I use VScode and genuine Stm32 VS Code Extension in 1.0.0 release.
I double check if USB3300 is properly soldered, maybe I damaged it when reworking solder on it, VDD1.8 are OK but no voltage on VDAA1.8, solders looks good and continuity seems OK between pad and capacitor. Maybe there is something wrong here.
Here the schematic and vscode project.
I have to test if my USB3300 works well.
Thanks for sharing solution
I try to port the code for f446vet target and custom board, the code hang in usb iniit when MX_USB_OTG_HS_PCD_Init is called:
I check if USB330 24M is properly generated: OK, also check if audio clock is generated: OK.
I use VScode and genuine Stm32 VS Code Extension in 1.0.0 release.
I double check if USB3300 is properly soldered, maybe I damaged it when reworking solder on it, VDD1.8 are OK but no voltage on VDAA1.8, solders looks good and continuity seems OK between pad and capacitor. Maybe there is something wrong here.
Here the schematic and vscode project.
I have to test if my USB3300 works well.
Edit: I try following tests:
first I set CubeMX USB_OTG_HS/External Phy to OTG/Dual_Role_Device instead of Device Only on a blank project, the code execute well (no hang on MX_USB_OTG_HS_USB_Init and I reach the main while(1) loop) but still no voltage on VDDA1.8 on USB3300. I don't know how to implement a USB CDC class in this mode because USB_Device and USB_Host are shadded on CubeMX/Middleware panel.
Second I set CubeMX USB_OTG_HS/External Phy to Device Only, I add a USB CDC class on a blank project and the code hang same way than explained before. No VDDA1.8 also.
For both tests I add the 24M MCO output fix and measure it with scope, looks good.
first I set CubeMX USB_OTG_HS/External Phy to OTG/Dual_Role_Device instead of Device Only on a blank project, the code execute well (no hang on MX_USB_OTG_HS_USB_Init and I reach the main while(1) loop) but still no voltage on VDDA1.8 on USB3300. I don't know how to implement a USB CDC class in this mode because USB_Device and USB_Host are shadded on CubeMX/Middleware panel.
Second I set CubeMX USB_OTG_HS/External Phy to Device Only, I add a USB CDC class on a blank project and the code hang same way than explained before. No VDDA1.8 also.
For both tests I add the 24M MCO output fix and measure it with scope, looks good.
Hello,
I'm in my customer labs equiped with great magnifier and iron solder, high speed scope also.
I just change the USB3300 and rework some of STM32 solders, issue seems to be fixed will check when come back to home with my dev suit.
I took opportunity to measure clock quality generated by STM32 PLL, for that I set MCO2 output to 49152000Hz, very high speed gpio setting, probe with a small coax cable directly connected to a 20GS/s monster scope of my customer.
Before these measure I tune the xtal load caps, initially to 5pF each I find 6.8pF is best (5pF give a 24000300Hz, 6.8pF give a 24000015Hz on MCO1 out), caps tune should be made for each layout and xtal ref.
Here some measures:
First the old way to have a look on jitter, trig on a square and show the next one with infinite persistence. Jitter looks small
I have one cycle to cyle measure (P1) and one N cycle measure (P4); jitter values looks similar to STM32 datasheet, no surprise here.
I check in temporal domain:
looking good.
So a max cycle cycle jitter around +/-300ps, a RMS (or mean) value about 30ps, I think not so bad.
I'm in my customer labs equiped with great magnifier and iron solder, high speed scope also
.I just change the USB3300 and rework some of STM32 solders, issue seems to be fixed
will check when come back to home with my dev suit.I took opportunity to measure clock quality generated by STM32 PLL, for that I set MCO2 output to 49152000Hz, very high speed gpio setting, probe with a small coax cable directly connected to a 20GS/s monster scope of my customer.
Before these measure I tune the xtal load caps, initially to 5pF each I find 6.8pF is best (5pF give a 24000300Hz, 6.8pF give a 24000015Hz on MCO1 out), caps tune should be made for each layout and xtal ref.
Here some measures:
First the old way to have a look on jitter, trig on a square and show the next one with infinite persistence. Jitter looks small
I have one cycle to cyle measure (P1) and one N cycle measure (P4); jitter values looks similar to STM32 datasheet, no surprise here.
I check in temporal domain:
looking good.
So a max cycle cycle jitter around +/-300ps, a RMS (or mean) value about 30ps, I think not so bad.
@__BriKs__ , that is great!
Please note the crude solution #4 in my previous post doesn't actually work right, so the DSD issue needs further investigations.
1. In Windows (Foobar2000 + wasapi push) it works for a single DoP sample rate after USBtoI2S device restart or reset. So, if you listen DoP64 first, all DoP64 files will play right, but if you switch to DoP128, the sound will be scrambled. After restart or reset, if the first DSD file is DoP128, it will work right, all files, but DoP64 will be scrambled.
2. In Linux (Volumio on x86/64 HTPC) both DoP64 &128 start scrambled, but if you use "seek" function for every file once (click on the file progress bar from current time stamp forward) it will start to play normally, but as soon as you start a new DSD file, it will start scrambled.
I presume it is about DMA/buffer reset/synchronization issue for DSD.
All PCM files works great on Windows and Linux, 44.1-384.
Please note the crude solution #4 in my previous post doesn't actually work right, so the DSD issue needs further investigations.
1. In Windows (Foobar2000 + wasapi push) it works for a single DoP sample rate after USBtoI2S device restart or reset. So, if you listen DoP64 first, all DoP64 files will play right, but if you switch to DoP128, the sound will be scrambled. After restart or reset, if the first DSD file is DoP128, it will work right, all files, but DoP64 will be scrambled.
2. In Linux (Volumio on x86/64 HTPC) both DoP64 &128 start scrambled, but if you use "seek" function for every file once (click on the file progress bar from current time stamp forward) it will start to play normally, but as soon as you start a new DSD file, it will start scrambled.
I presume it is about DMA/buffer reset/synchronization issue for DSD.
All PCM files works great on Windows and Linux, 44.1-384.