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

[Farid Azhar]

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?

[Neeraj Dantu]

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

[Farid Azhar]

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.

[Neeraj Dantu]

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

[Farid Azhar]

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.

[Neeraj Dantu]

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

[Farid Azhar]

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

[Farid Azhar]

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$

[Neeraj Dantu]

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

[Farid Azhar]

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