Closed insolace closed 10 months ago
Can you try to change 0xC0
address with 0x180
for the 0x01
endpoint, to see if that helps?
Hi,
I tried setting 0x180 for the 0x01 endpoint but that broke things.
On Thu, Oct 19, 2023 at 12:57 AM Hypnotriod @.***> wrote:
Can you try to change 0xC0 address with 0x180 for the 0x01 endpoint, to see if that helps?
— Reply to this email directly, view it on GitHub https://github.com/Hypnotriod/midi-box-stm32/issues/9#issuecomment-1770265688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQHABJC4OKCFE7MBHNS3TYADMNVAVCNFSM6AAAAAA6FV42COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQGI3DKNRYHA . You are receiving this because you authored the thread.Message ID: @.***>
I guess it has only 256 half words of pma. And as always I cannot find any sutable information about pma mapping in g0 mcu. Do you have any documentation which says that this device family have or have not pma onboard?
I had to dig, but STM was kind enough to put the details in a 1400 page pdf :).
Page 1265, section 37.4.1:
The size of the packet memory is 2048 bytes, structured as 512 words of 32 bits.
On Sat, Oct 28, 2023 at 1:59 AM Hypnotriod @.***> wrote:
I guess it has only 256 half words of pma. And as always I cannot find any sutable information about pma mapping in g0 mcu. Do you have any documentation which says that this device family have or have not pma onboard?
— Reply to this email directly, view it on GitHub https://github.com/Hypnotriod/midi-box-stm32/issues/9#issuecomment-1783752791, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQHAEH3HRKJKXAFLAXT6LYBTCN5AVCNFSM6AAAAAA6FV42COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTG42TENZZGE . You are receiving this because you authored the thread.Message ID: @.***>
So 0x0180
address is not "out of bounds" than... But 0xC0
should work as well.
Anyway I'm not sure that such kind of device needs a double buffer at 12Mbit.
You can make a speed test to see how many messages you can squeeze. Just make sure that your are sending 16 of them each transaction.
We haven’t brought up firmware updates on this platform, which is where this would matter. We do double buffer in our 8bit processors, where fw updates are critical.I’ll work up a test and pet you know.On Oct 29, 2023, at 4:31 AM, Hypnotriod @.***> wrote: So 0x0180 address is not "out of bounds" than... But 0xC0 should work as well. Anyway I'm not sure that you actually need a double buffer for 12Mbit device. An don't think that it suppose to. You can make a speed test to see how many messages you can squeeze. Just make sure that your are sending 16 of them each transaction.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
It seems that USB Bulk Endpoint double buffering has some issues, at least with the G0 HAL driver that I'm using.
I've made the below modifications which result in the code using the double buffer method to write to the PMA, but then USBD_MIDI_DataIn() is never called which means USBD_MIDI_GetState(&hUsbDeviceFS) never returns to MIDI_IDLE.
In STMCube I've set USB_DRD_FS->Parameter Settings->bulk double buffer = Enabled
In usbd_conf.c I've modified the PMAConfig for double buffers: HAL_PCDEx_PMAConfig((PCD_HandleTypeDef)pdev->pData , 0x01 , PCD_DBL_BUF, 0xC0); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef)pdev->pData , 0x81 , PCD_DBL_BUF, 0x100);
In stm32g0xx_ll_usb.c I've added:
include "stm32g0xx_ll_usb.h"
define USE_USB_DOUBLE_BUFFER 1