512-861-3400Log inCreate Account

Connecting USB-C port to Cortex-M on OSD32MP1-RED board

Forums › Reference, Evaluation, and Development Boards › OSD32MP1-RED › Connecting USB-C port to Cortex-M on OSD32MP1-RED board

Tagged: 

Viewing 9 reply threads
  • Author
    Posts
    • November 25, 2021 at 6:04 pm #11936
      Farid AzharFarid Azhar
      Participant

        We’ve configured the OSD32MP1-RED board’s USB-C port as Mass Storage Device and disabled the all other ports (Ethernet, CAN, USB-A).
        When the board’s USB-C port is connected to a Laptop (Ubuntu / Windows) it takes about 35-sec to enumarte and show the USB drive icon on Laptop.
        We want to reduce this USB enumartion time to around 5-sec.
        Is it posible to connect the USB-C port to Cortex-M, will it reduce the USB enumrtaion time and is there USB driver available for Cortex-M.
        If it is possible, how to proceed?

      • November 29, 2021 at 1:10 pm #11940
        Neeraj Dantu
        Moderator

          Farid,

          USB enumeration happens as part of the boot process as well as once the board boot is complete. What I think you are experiencing is the delay between when the board powers up and when the kernel finishes boot up, which is when the enumeration happens. The actual enumeration should take ~1 sec once the cable is connected.

          You can verify this by using the barrel connector to power the board. Once the board is booted up(this would take ~35 sec), you can connect the USB cable to see it come up instantly.

          Finally, USB peripheral cannot be accessed by the M4 core. You will need to use the A7 core to control the USB peripheral.

          Best,
          Neeraj

        • December 8, 2021 at 10:26 pm #11960
          Farid AzharFarid Azhar
          Participant

            Hi Neeraj,
            Thanks for your response. I understood, we can not control USB peripheral via M4 core.
            We have made some HW changes to the USB-C (OTG) port, since we want to use it as a Device (not OTG).
            We have replaced the USB-C port wkth a USB-A port and connected it directly to SiP USB signals (USB_DM2, USB_DP2) passing through an ESD.
            We have removed the USB Type-C controller (U24 – STUSB1600AQTR) and associated circuitry.
            USB_DM2 -> ESD -> USB-A (Device)
            USB_DP2 -> ESD -> USB-A (Device)
            I beleive I have to make some changes in DeviceTree and Kernel to make it work, but not sure where to do these changes.
            I would appreciate if you could give me some direction.
            Thanks.

            Farid.

          • December 13, 2021 at 10:02 am #11974
            Neeraj Dantu
            Moderator

              Farid,

              Please taka a look at section 10.1.12 on the hardware getting started guide for STM32MP1: https://www.st.com/resource/en/application_note/dm00389996-getting-started-with-stm32mp151-stm32mp153-and-stm32mp157-line-hardware-development-stmicroelectronics.pdf for all possible USB configurations including using USB2 port as HOST. You can also find an example circuit in Sheet 6 of OSD32MP1 RED: https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/.

              An example of the device tree for using USB1 as HOST port is shown here as part of OSD32MP1-RED device tree: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/linux-v5.10-r0/stm32mp157c-osd32mp1-red.dts#L1400.

              Best,
              Neeraj

            • December 13, 2021 at 6:36 pm #11977
              Farid AzharFarid Azhar
              Participant

                Hi Neeraj,
                Thanks for your response.
                I looked at the links you provided, but didn’t get the answer I’m looking for.
                We want to configure the USB2 in Client/Device mode not the Host or OTG. We’ve made the HW changes on USB-C (OTG) circuitry and want to know what changes we need to do in the Devcietree to reflect this changes.

              • December 14, 2021 at 1:03 pm #11982
                Neeraj Dantu
                Moderator

                  Farid,

                  My apologies, I assumed you wanted USB2 to be a HOST port because you are connecting a USB type-A connector. If you are intending to use USB2 as a device, you can use OSD32MP1-BRK device tree(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts). You can find the schematics for BRK here: https://octavosystems.com/docs/osd32mp1-brk-schematics/.

                  Best,
                  Neeraj

                • March 22, 2022 at 8:56 pm #12195
                  Farid AzharFarid Azhar
                  Participant

                    Hi Neeraj,

                    We’ve received our custom board from manufacturing.
                    We’ve changed the USB-C (OTG) to USB-A (Device). I’ve modified the USB node (usbotg_hs) in kernel and u-boot dts files same as BRK board dts files. We are now running on SDKv3.

                    When I tried to flash the eMMC using STM32_Programmer_CLI (on ubuntu laptop), it failed after downloading the partition 0x03 binary.
                    Following logs shows USB devcice failed to re-connect and download partition 0x04.
                    lsusb shows usb is not in dfu mode anymore.

                    I also tried to flash a BRK board SD card with STM32_Programmer_CLI and same tsv file, I got exactly the same error.
                    I would appreciate any help.
                    Thanks.

                    Farid.

                    :
                    Flashlayout Programming …
                    [==================================================] 100%
                    Running Flashlayout Partition …
                    Flashlayout partition started successfully

                    Memory Programming …
                    Opening and parsing file: fip-stm32mp157c-osd32mp1-red-trusted.bin
                    File : fip-stm32mp157c-osd32mp1-red-trusted.bin
                    Size : 1021582 Bytes
                    Partition ID : 0x03

                    Download in Progress:
                    [==================================================] 100%

                    File download complete
                    Time elapsed during download operation: 00:00:01.986

                    RUNNING Program …
                    PartID: :0x03

                    Reconnecting the device …

                    Error:
                    Unable to reconnect the target device: time out expired

                    Error: Start operation failed at partition 0x03
                    Error: TSV flashing service failed

                  • March 23, 2022 at 9:11 pm #12206
                    Farid AzharFarid Azhar
                    Participant

                      I verified USB-A is working for flashing, downloading TF-A binaries to SRAM and DDR.
                      It is failing when trying to download TF-A binary to eMMC boot1 partition ID: 0x04 (first boot area) at offset 0x0.

                      Heres are the complete logs …

                      ../deploy$ STM32_Programmer_CLI -c port=USB1 -log ~/emmc_flash.log -vb 1 -w FlashLayout_emmc_stm32mp157c-osd32mp1-new-trusted.tsv
                      ——————————————————————-
                      STM32CubeProgrammer v2.8.0
                      ——————————————————————-

                      Log output file: ~/emmc_flash.log

                      USB speed : High Speed (480MBit/s)
                      Manuf. ID : STMicroelectronics
                      Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
                      SN : 004400343239511837383434
                      FW version : 0x0110
                      Device ID : 0x0500
                      Device name : STM32MP1
                      Device type : MPU
                      Device CPU : Cortex-A7

                      Start Embedded Flashing service

                      Memory Programming …
                      Opening and parsing file: tf-a-stm32mp157c-osd32mp1-new-usb.stm32
                      File : tf-a-stm32mp157c-osd32mp1-new-usb.stm32
                      Size : 225572 Bytes
                      Partition ID : 0x01

                      Download in Progress:
                      [==================================================] 100%

                      File download complete
                      Time elapsed during download operation: 00:00:00.493

                      RUNNING Program …
                      PartID: :0x01
                      Start operation done successfully at partition 0x01

                      Flashlayout Programming …
                      [==================================================] 100%
                      Running Flashlayout Partition …
                      Flashlayout partition started successfully

                      Memory Programming …
                      Opening and parsing file: fip-stm32mp157c-osd32mp1-new-trusted.bin
                      File : fip-stm32mp157c-osd32mp1-new-trusted.bin
                      Size : 1021582 Bytes
                      Partition ID : 0x03

                      Download in Progress:
                      [==================================================] 100%

                      File download complete
                      Time elapsed during download operation: 00:00:01.267

                      RUNNING Program …
                      PartID: :0x03

                      Reconnecting the device …

                      USB speed : High Speed (480MBit/s)
                      Manuf. ID : STMicroelectronics
                      Product ID : USB download gadget@Device ID /0x500, @Revision ID /0x2001, @Name /STM32MP157C?? Rev.Z,
                      SN : 004400343239511837383434
                      FW version : 0x0110
                      Device ID : 0x0500
                      Start operation done successfully at partition 0x03
                      Error: an error occured while uploading data from the virtual partition 0xF1
                      Received PhaseID == 0xFF, system is going to reboot
                      ../deploy$

                    • March 28, 2022 at 10:06 am #12216
                      Neeraj Dantu
                      Moderator

                        Farid,

                        Can you take a look at the logs from the board(out of UART4 console)? It seems like error is occurring at U-boot stage on the board before DFU actions are performed. The board console logs will tell you exactly where it is getting stuck.

                        Please also try to update your Cube Programmer version to 2.9 or greater. We have seen failures like then when using an incompatible version of Cube Programmer.

                        Best,
                        Neeraj

                      • April 5, 2022 at 3:08 pm #12244
                        Farid AzharFarid Azhar
                        Participant

                          Hi Neeraj,

                          Thanks for your response.
                          You are right. The problem appears to be in dfu driver. I added lots of debug traces and and Flash the same eMMC image (.tsv, .stm32 etc) to RED board and our NEW board.
                          Flashing on RED board works OK but fail on NEW board.
                          Comparing the logs shows that NEW board it is failing at dfu_read() function, it is trying to download the binary file from eMMC rootfs partition Not from the virtual partition.
                          I tested on Cube Programmer version 2.10.

                          Following are some logs and code reference where these logs are captured.

                          https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L637
                          *** On RED board ***
                          DFU alt settings list:
                          dev: eMMC alt: 0 name: @fsbl1/0x04/1*8Me layout: RAW_ADDR
                          dev: eMMC alt: 1 name: @fsbl2/0x05/1*8Me layout: RAW_ADDR
                          dev: eMMC alt: 2 name: @fip/0x06/1*2Me layout: RAW_ADDR
                          dev: eMMC alt: 3 name: @boot/0x21/1*64Me layout: RAW_ADDR
                          dev: eMMC alt: 4 name: @vendorfs/0x22/1*16Me layout: RAW_ADDR
                          dev: eMMC alt: 5 name: @rootfs/0x23/1*14945Me layout: RAW_ADDR
                          dev: VIRT alt: 6 name: @virtual/0xf1/1*512Be layout: RAW_ADDR
                          dev: VIRT alt: 7 name: @OTP/0xf2/1*512Be layout: RAW_ADDR
                          dev: VIRT alt: 8 name: @PMIC/0xf4/1*8Be layout: RAW_ADDR
                          *** On NEW board ***
                          DFU alt settings list:
                          dev: eMMC alt: 0 name: @fsbl1/0x04/1*4Me layout: RAW_ADDR
                          dev: eMMC alt: 1 name: @fsbl2/0x05/1*4Me layout: RAW_ADDR
                          dev: eMMC alt: 2 name: @fip/0x06/1*2Me layout: RAW_ADDR
                          dev: eMMC alt: 3 name: @boot/0x21/1*64Me layout: RAW_ADDR
                          dev: eMMC alt: 4 name: @vendorfs/0x22/1*16Me layout: RAW_ADDR
                          dev: eMMC alt: 5 name: @rootfs/0x23/1*119293Me layout: RAW_ADDR
                          dev: VIRT alt: 6 name: @virtual/0xf1/1*512Be layout: RAW_ADDR
                          dev: VIRT alt: 7 name: @OTP/0xf2/1*512Be layout: RAW_ADDR
                          dev: VIRT alt: 8 name: @PMIC/0xf4/1*8Be layout: RAW_ADDR

                          Note: alt 0, 1 and 5 names are different. Is this due to eMMC difference on two boards?

                          https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L462
                          dfu_read()
                          dfu_read: name: @virtual/0xf1/1*512Be buf: 0xddf2d7c0 size: 0x1000 p_num: 0x0 i_buf: 0x00000000 => On RED board
                          dfu_read: name: @rootfs/0x23/1*119293Me buf: 0xddf2d7c0 size: 0x1000 p_num: 0x0 i_buf: 0x00000000 => On NEW board

                          https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L302
                          dfu_transaction_initiate()
                          dfu_transaction_initiate: @virtual/0xf1/1*512Be dfu->r_left: 512 [B] => On RED board
                          dfu_transaction_initiate: @rootfs/0x23/1*119293Me dfu->r_left: 533725184 [B] => On NEW board

                          https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L483
                          dfu_read()
                          if (ret < size) {
                          (ret 9 < size 4096) => On RED Board
                          (ret 4096 < size 4096) => On NEW board

                          RED board satisfies above condition, print “UPLOAD … done” message and moves to next stage
                          NEW board fails above condition and stuck.

                          I coundn’t figure out what is the root cause of failure on NEW board.
                          Is some thing different in “dfu_alt_info” environment? how to update it?
                          Is this due to eMMC difference between two boards or something missing in dts files.

                          Your help is much appreciated.

                      • Author
                        Posts
                      Viewing 9 reply threads
                      • You must be logged in to reply to this topic.

                      Octavo Systems LLC all rights reserved
                      OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.