Skip to main content
Visitor II
May 14, 2024
Solved

Attempting to change the USB Phy address via the DAD field within the DCFG register.

  • May 14, 2024
  • 2 replies
  • 1864 views

I'm working on emulating multiple USB devices using an STM32F4xx microcontroller. My goal is to dynamically change the USB controller's address at each SOF to cover the addresses of all my devices. However, I've encountered an issue: when I read the address from the hpcd_OTG structure, from hUsbDeviceFS and the DAD field, it differs from the address shown in Wireshark. Additionally, when I attempt to change the address, I don't receive any requests. The only way I can receive USB packets intended for that address is by resetting the address to 0. Any insights on why this might be happening?

I am using "(void)USBD_LL_SetUSBAddress(pdev, dev_addr);" to set the address in the DCFG register and DAD fields.

I have seen the Wrong software-read OTG_FS_DCFG register values erratum but the real problem is that only address 0 work.

    This topic has been closed for replies.
    Best answer by FBL

    Hi @Krum 

    I'm not sure that would be possible by software. Since it is not compliant to spec, it would not be certified and never supported.

    2 replies

    Technical Moderator
    May 30, 2024

    Hi @Krum 

    As mentioned in the RM, here is what the application must do when it receives a SetAddress command in a SETUP packet.

    1. Program the OTG_DCFG register with the device address received in the SetAddress command
    2. Program the core to send out a status IN packet

    At application level, when using USBD_LL_SetUSBAddress(), you need to call  HAL_PCD_SetAddress() to set the address command. After that USBD_CtlSendStatus() sends a ZLP to the host so that host will be able to receive the status stage and device switch to new address. 

    This implementation is already detailed in the ST's Device Middleware.

    I hope this is helpful.

    KrumAuthor
    Visitor II
    June 1, 2024

     

    Hi @FBL,

    I've already read the RM for the OTG_FS. The SET_ADDRESS command issued by the PC is received on the STM32, and I can decode it fine and assign the address in the OTG_DCFG register. However, I want to change this address without receiving a SET_ADDRESS command. I want to change it upon receiving a SOF from the host.

    The idea is to first enumerate as a certain device, and after this enumeration, keep the address and alternate to another address with each SOF.

    The problem is that the DCFG register doesn't seem to allow that. It's stated that "Do not make changes to this register after initial programming" and when I try to manually change the address, I can't be sure that it has been changed due to the "Wrong software-read OTG_FS_DCFG register values erratum". But what I'm sure of is that I don't received interruption (like RXFLVL) for new transaction destined to this address.

    What's bugging me is the difference in the address between the application, the DCFG register, and Wireshark. Does anyone know why this might be happening?

     

    Technical Moderator
    June 5, 2024

    Hi @Krum 

    Changing the USB device address upon receiving a Start of Frame (SOF) from the host without a SET_ADDRESS command is not compliant with the USB specification. The USB device address is a unique identifier for USB devices on the bus, and it is assigned during the enumeration process by the host using a SET_ADDRESS command. The SOF packet is sent by the host every 1ms (FS) and serves as a timing reference for devices on the bus. It is not used to set or change the device address.

    KrumAuthor
    Visitor II
    June 9, 2024

    Hi @FBL,

    Even if it doesn't fully comply with the USB specification, can the USB controller still update its address through software?

    If yes, theoretically, it will work, or is its non-compliance a complete barrier ?

    FBLAnswer
    Technical Moderator
    June 10, 2024

    Hi @Krum 

    I'm not sure that would be possible by software. Since it is not compliant to spec, it would not be certified and never supported.