USB PMA addresses

I’m trying to understand how the USB peripheral works on stm32f1, and I’ve noticed that the Maple core allocates USB PMA buffers starting at offset 0x40 instead of at 0x00. Does anybody know why? Is the initial 0x40 reserved for something? (CAN?)

Maybe http://docs.leaflabs.com/static.leaflab … b_config.h

/* insert license */

#ifndef __USB_CONFIG_H
#define __USB_CONFIG_H

#include "usb_lib.h"
#include "gpio.h"

/******************************************************************************
******************************************************************************
***
*** HACK ALERT
***
*** FIXME FIXME FIXME FIXME
***
*** A bunch of board-specific #defines that are only used by the
*** USB routines got put into libmaple.h for what appear to be
*** historical reasons. I'm [mbolivar] putting them in here for
*** now, so that we can treat the usb/ directory as a black box,
*** freeing the rest of libmaple/ to be implemented as a
*** general-purpose STM32 library. All of this REALLY needs to get
*** moved into wirish when we get a chance to redo the USB stack.
***
******************************************************************************
*****************************************************************************/

#define VCOM_ID_VENDOR 0x1EAF
#define RESET_DELAY (100000)
#define USB_CONFIG_MAX_POWER (100 >> 1)

#if defined(BOARD_maple) || defined(BOARD_maple_RET6)

/* USB Identifier numbers */
#define VCOM_ID_PRODUCT 0x0004
#define USB_DISC_DEV GPIOC
#define USB_DISC_PIN 12

#elif defined(BOARD_maple_mini)

#define VCOM_ID_PRODUCT 0x0004
#define USB_DISC_DEV GPIOB
#define USB_DISC_PIN 9

#elif defined(BOARD_maple_native)

#define VCOM_ID_PRODUCT 0x0004
#define USB_DISC_DEV GPIOB
#define USB_DISC_PIN 8

#else

#error ("Sorry! the USB stack relies on LeafLabs board-specific " \
"configuration right now. If you want, you can pretend you're one " \
"of our boards; i.e., #define BOARD_maple, BOARD_maple_mini, or " \
"BOARD_maple_native according to what matches your MCU best. " \
"You should also take a look at libmaple/usb/descriptors.c; we make " \
"some assumptions there that you probably won't like.")

#endif

/******************************************************************************
******************************************************************************
***
*** END HACK
***
******************************************************************************
*****************************************************************************/

/* choose addresses to give endpoints the max 64 byte buffers */
#define USB_BTABLE_ADDRESS 0x00
#define VCOM_CTRL_EPNUM 0x00
#define VCOM_CTRL_RX_ADDR 0x40
#define VCOM_CTRL_TX_ADDR 0x80
#define VCOM_CTRL_EPSIZE 0x40

#define VCOM_TX_ENDP ENDP1
#define VCOM_TX_EPNUM 0x01
#define VCOM_TX_ADDR 0xC0
#define VCOM_TX_EPSIZE 0x40

#define VCOM_NOTIFICATION_ENDP ENDP2
#define VCOM_NOTIFICATION_EPNUM 0x02
#define VCOM_NOTIFICATION_ADDR 0x100
#define VCOM_NOTIFICATION_EPSIZE 0x40

#define VCOM_RX_ENDP ENDP3
#define VCOM_RX_EPNUM 0x03
#define VCOM_RX_ADDR 0x110
#define VCOM_RX_EPSIZE 0x40
#define VCOM_RX_BUFLEN (VCOM_RX_EPSIZE*3)

#define bMaxPacketSize 0x40 /* 64B, maximum for USB FS Devices */

#define NUM_ENDPTS 0x04

/* handle all usb interrupts */
#define ISR_MSK (CNTR_CTRM | \
CNTR_WKUPM | \
CNTR_SUSPM | \
CNTR_ERRM | \
CNTR_SOFM | \
CNTR_ESOFM | \
CNTR_RESETM)

#define F_SUSPEND_ENABLED 1

#endif

[arpruss – Sat Jan 27, 2018 4:21 pm] –
I’m trying to understand how the USB peripheral works on stm32f1, and I’ve noticed that the Maple core allocates USB PMA buffers starting at offset 0x40 instead of at 0x00. Does anybody know why? Is the initial 0x40 reserved for something? (CAN?)

Any reference (link) to a document (core file)?

The reference manual may show some details, and there are webpages showing how the USB Serial communication works, but basically besides the RX and TX endpoints you have a control endpoint. The control endpoint itself needs a buffer and is placed first.
Those addresses are in reference to the USB decicated RAM.
The start of that RAM is the Endpoint table, so the buffer structure is like this
00-nn Endpoint definition table
nn – xx buffer 1
xx – yy buffer 2
…

Victor: So the reason the first buffer starts at 0x40 rather than 0x00 is to leave room for the endpoint table. That makes sense. And indeed the endpoint table is 0x40 bytes long (eight endpoints x 4 x uint16).

[mrburnette – Sat Jan 27, 2018 5:27 pm] –
#define VCOM_NOTIFICATION_ENDP ENDP2
#define VCOM_NOTIFICATION_EPNUM 0x02
#define VCOM_NOTIFICATION_ADDR 0x100
#define VCOM_NOTIFICATION_EPSIZE 0x40

#define VCOM_RX_ENDP ENDP3
#define VCOM_RX_EPNUM 0x03
#define VCOM_RX_ADDR 0x110
#define VCOM_RX_EPSIZE 0x40

USB makes me crazy(ier.)

All I know about USB I learned from V-USB playing around years ago on AVR. Nice thing about V-USB is the documentation is rather straightforward.

http://vusb.wikidot.com/driver-api

Ray

[arpruss – Sun Jan 28, 2018 12:53 am] –
By the way, isn’t it a bit strange that VCOM_RX_ADDR = VCOM_NOTIVATION_ADDR + 0x10, instead of VCOM_RX_ADDR = VCOM_NOTIVATION_ADDR + 0x40, given that the size of the VCOM_NOTIFICATION packet buffer is 0x40? Is this a bug? Or am I misunderstanding something about how all this works.

This may be indeed a bug.
Either VCOM_NOTIFICATION_EPSIZE should be 0x10 or VCOM_RX_ADDR should be 0x140.

EP3 overlapping with EP2 is not disturbing so far because ENDP2 was (and still is) not used by any application, AFAIK.

However, none of these defines can be found in the core.

So please provide a link to a core file in which you think there is something wrong.

[stevestrong – Sun Jan 28, 2018 8:41 am] –

[arpruss – Sun Jan 28, 2018 12:53 am] –
By the way, isn’t it a bit strange that VCOM_RX_ADDR = VCOM_NOTIVATION_ADDR + 0x10, instead of VCOM_RX_ADDR = VCOM_NOTIVATION_ADDR + 0x40, given that the size of the VCOM_NOTIFICATION packet buffer is 0x40? Is this a bug? Or am I misunderstanding something about how all this works.

This may be indeed a bug.
Either VCOM_NOTIFICATION_EPSIZE should be 0x10 or VCOM_RX_ADDR should be 0x140.

EP3 overlapping with EP2 is not disturbing so far because ENDP2 was (and still is) not used by any application, AFAIK.

However, none of these defines can be found in the core.

So please provide a link to a core file in which you think there is something wrong.

Here it is.

I would make the management size be 0x10. That seems to work in my USBHID library.

#define USB_CDCACM_CTRL_ENDP 0
#define USB_CDCACM_CTRL_RX_ADDR 0x40
#define USB_CDCACM_CTRL_TX_ADDR 0x80
#define USB_CDCACM_CTRL_EPSIZE 0x40

#define USB_CDCACM_TX_ENDP 1
#define USB_CDCACM_TX_ADDR 0xC0
#define USB_CDCACM_TX_EPSIZE 0x40

#define USB_CDCACM_MANAGEMENT_ENDP 2
#define USB_CDCACM_MANAGEMENT_ADDR 0x100
#define USB_CDCACM_MANAGEMENT_EPSIZE 0x40

#define USB_CDCACM_RX_ENDP 3
#define USB_CDCACM_RX_ADDR 0x110
#define USB_CDCACM_RX_EPSIZE 0x40


I think you are right in that the size should be 0x10, or the next buffer should start 0x30 forward.
We should probably check somewhere to see which one is better to do, or perhaps the management endpoint never send packets larger than 0x10, and that’s we haven’t noticed any issue yet.
If I remember right the RX and TX endpoints, because they are bulk transfer type in full speed mode packets can be up to 0x40bytes in size, can’t use packets larger than 0x40, so even if the RX endpoint was let’s say 0x60, the host would still not send any packet larger than that.
Trying to check if I find anything about the management endpoint.

In the F4 the CDC CMD endpoint max packet size is set to 8 bytes, so likely ok to use 16 bytes. Still trying to find something in the CDC documents that says whats the minimum size for the command endpoint.

Looking at the code in the core, the management endpoint is configured for device-to-host communication, but there is no code to actually send anything through this endpoint. That’s why we haven’t run into any problems with this bug. In particular, it should be safe to reduce the size to 0x10, since we don’t use it at all.

[arpruss – Mon Jan 29, 2018 5:04 am] –
Looking at the code in the core, the management endpoint is configured for device-to-host communication, but there is no code to actually send anything through this endpoint. That’s why we haven’t run into any problems with this bug. In particular, it should be safe to reduce the size to 0x10, since we don’t use it at all.

Didn’t check today, but when I checked the other day I thought only the TX endpoint is configured. Since USB names TX and RX from the host perspective, a TX endpoint means data from host to device.
I didn’t check what it is used for, I thought it would be for things such as communicating when DTR is active/inactive, etc, but that was a guess without looking at the code, so if you are right that’s why we didn’t run into problems.

It’s true that USB names things from the host’s point of view, but the Maple cdcacm code uses “tx/rx” from the device point of view, but “IN/OUT” from the host’s point of view. Yes, that’s confusing!

Here’s the endpoint config in the USB descriptor in the code.
.ManagementEndpoint = {
.bLength = sizeof(usb_descriptor_endpoint),
.bDescriptorType = USB_DESCRIPTOR_TYPE_ENDPOINT,
.bEndpointAddress = (USB_DESCRIPTOR_ENDPOINT_IN |
USB_CDCACM_MANAGEMENT_ENDP),
.bmAttributes = USB_EP_TYPE_INTERRUPT,
.wMaxPacketSize = USB_CDCACM_MANAGEMENT_EPSIZE,
.bInterval = 0xFF,
},