Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

USB do not works if bootloader badly use the device before #34134

Closed
wysman opened this issue Apr 8, 2021 · 13 comments
Closed

USB do not works if bootloader badly use the device before #34134

wysman opened this issue Apr 8, 2021 · 13 comments
Assignees
@jfischer-no @erwango
Labels
area: MCUBoot area: USB Universal Serial Bus bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug Waiting for response Waiting for author's response

Comments

@wysman
Copy link
Contributor

wysman commented Apr 8, 2021

Describe the bug
From the version 2.5 of zephyr-os, the USB-ACM of mcuboot is not working anymore, but the chain loading of the application slot is working. My application is using USB too. I think the previous failed init of USB from MCUBoot prevent the zephyr-os usb init to works.

Work around

  • Use mcuboot provided and compiled for Zephyr-os 2.4
  • Use Application compiled for Zephyr-os 2.5.

Related issue (mcuboot)
mcu-tools/mcuboot#972

To Reproduce
Get a STM3F4 dev board
Use MCUBoot as bootloader with USB-ACM enabled.
Use samples/subsys/usb/hid as application

Expected behavior
Zephyr must do a more complete cleanup of the USB device to ensure a correct working state.

Impact
We can not use USB in the zephyr-os based application.

Logs and console output (Board)
usb_enable() works fine, no error

Logs and console output (Linux host)
avril 08 13:33:40 cortex kernel: usb 1-3: new full-speed USB device number 90 using xhci_hcd
avril 08 13:33:40 cortex kernel: usb 1-3: device descriptor read/64, error -71
avril 08 13:33:40 cortex kernel: usb 1-3: device descriptor read/64, error -71
avril 08 13:33:40 cortex kernel: usb 1-3: new full-speed USB device number 91 using xhci_hcd
avril 08 13:33:41 cortex kernel: usb 1-3: device descriptor read/64, error -71
avril 08 13:33:41 cortex kernel: usb 1-3: device descriptor read/64, error -71
avril 08 13:33:41 cortex kernel: usb usb1-port3: attempt power cycle
avril 08 13:33:42 cortex kernel: usb 1-3: new full-speed USB device number 92 using xhci_hcd
avril 08 13:33:42 cortex kernel: usb 1-3: Device not responding to setup address.
avril 08 13:33:42 cortex kernel: usb 1-3: Device not responding to setup address.
avril 08 13:33:42 cortex kernel: usb 1-3: device not accepting address 92, error -71
avril 08 13:33:42 cortex kernel: usb 1-3: new full-speed USB device number 93 using xhci_hcd
avril 08 13:33:42 cortex kernel: usb 1-3: Device not responding to setup address.
avril 08 13:33:42 cortex kernel: usb 1-3: Device not responding to setup address.
avril 08 13:33:43 cortex kernel: usb 1-3: device not accepting address 93, error -71
avril 08 13:33:43 cortex kernel: usb usb1-port3: unable to enumerate USB device

Environment (please complete the following information):

  • OS: Linux
  • SDK: v0.12.4
  • Zephyr-os: v2.5.0
@wysman wysman added the bug The issue is a bug, or the PR is fixing a bug label Apr 8, 2021
@carlescufi
Copy link
Member

Are you enabling CONFIG_MCUBOOT_CLEANUP_ARM_CORE in MCUboot?

@carlescufi carlescufi added area: MCUBoot area: USB Universal Serial Bus platform: STM32 ST Micro STM32 labels Apr 8, 2021
@jfischer-no
Copy link
Collaborator

USB-ACM of mcuboot is not working anymore

I guess it is Zephyr OS with USB device stack, CDC-ACM class support and MCUboot as application?
Can you please test samples/subsys/usb/cdc_acm without MCUboot and any modifications?

@wysman
Copy link
Contributor Author

wysman commented Apr 8, 2021

@carlescufi I have made a test with the CONFIG_MCUBOOT_CLEANUP_ARM_CORE. It's do not works better.

@wysman
Copy link
Contributor Author

wysman commented Apr 8, 2021

@jfischer-no I have test the samples/subsys/usb/cdc_acm application without mcuboot. It's do not works.

Logs and console output (Board)
Booting Zephyr OS build zephyr-v2.5.0
[00:00:00.054,000] cdc_acm_echo: Wait for DTR

Logs and console output (Linux host)
avril 08 17:35:07 cortex kernel: usb 1-2.1: new full-speed USB device number 76 using xhci_hcd
avril 08 17:35:07 cortex kernel: usb 1-2.1: device descriptor read/64, error -32
avril 08 17:35:07 cortex kernel: usb 1-2.1: device descriptor read/64, error -32
avril 08 17:35:07 cortex kernel: usb 1-2.1: new full-speed USB device number 77 using xhci_hcd
avril 08 17:35:07 cortex kernel: usb 1-2.1: device descriptor read/64, error -32
avril 08 17:35:07 cortex kernel: usb 1-2.1: device descriptor read/64, error -32
avril 08 17:35:08 cortex kernel: usb 1-2-port1: attempt power cycle
avril 08 17:35:08 cortex kernel: usb 1-2.1: new full-speed USB device number 78 using xhci_hcd
avril 08 17:35:08 cortex kernel: usb 1-2.1: Device not responding to setup address.
avril 08 17:35:08 cortex kernel: usb 1-2.1: Device not responding to setup address.
avril 08 17:35:09 cortex kernel: usb 1-2.1: device not accepting address 78, error -71
avril 08 17:35:09 cortex kernel: usb 1-2.1: new full-speed USB device number 79 using xhci_hcd
avril 08 17:35:09 cortex kernel: usb 1-2.1: Device not responding to setup address.
avril 08 17:35:09 cortex kernel: usb 1-2.1: Device not responding to setup address.
avril 08 17:35:09 cortex kernel: usb 1-2.1: device not accepting address 79, error -71
avril 08 17:35:09 cortex kernel: usb 1-2-port1: unable to enumerate USB device

@jfischer-no
Copy link
Collaborator

jfischer-no commented Apr 9, 2021 •
edited
Loading

@wysman can you please check STM32 relevant release-notes-2.5. Maybe your issue is related to pinmux changes, "STM32 pinmux driver has been reworked to allow pin configuration using devicetree definitions. The previous C macros are now deprecated."

@jfischer-no
Copy link
Collaborator

To Reproduce
Get a STM3F4 dev board

Exactly which board supported by Zephyr OS can be used to reproduce this problem?

@wysman
Copy link
Contributor Author

wysman commented Apr 9, 2021

@jfischer-no I have test the sample on our custom board with your custom DTS. We have migrated the pinmux stuff during our 2.4 to 2.5 migration, and USB is working with the older mcuboot.

Our custom board are based on STM32F412RG.

@erwango
Copy link
Member

erwango commented Apr 9, 2021

I've just had a try using nucleo_f429zi on samples/subsys/usb/cdc_acm and it seems to work fine, on latest master (zephyr-v2.5.0-2093-ga074b335db):

[74920.149870] usb 1-1: USB disconnect, device number 20
[74920.641092] usb 1-1: new full-speed USB device number 21 using xhci_hcd
[74920.791475] usb 1-1: New USB device found, idVendor=2fe3, idProduct=0001, bcdDevice= 2.05
[74920.791481] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[74920.791485] usb 1-1: Product: Zephyr CDC ACM sample
[74920.791488] usb 1-1: Manufacturer: ZEPHYR
[74920.791491] usb 1-1: SerialNumber: 373038323236510B
[74920.793837] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

@jfischer-no jfischer-no added the priority: low Low impact/importance bug label Apr 9, 2021
@carlescufi
Copy link
Member

I've just had a try using nucleo_f429zi on samples/subsys/usb/cdc_acm and it seems to work fine, on latest master (zephyr-v2.5.0-2093-ga074b335db):

[74920.149870] usb 1-1: USB disconnect, device number 20
[74920.641092] usb 1-1: new full-speed USB device number 21 using xhci_hcd
[74920.791475] usb 1-1: New USB device found, idVendor=2fe3, idProduct=0001, bcdDevice= 2.05
[74920.791481] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[74920.791485] usb 1-1: Product: Zephyr CDC ACM sample
[74920.791488] usb 1-1: Manufacturer: ZEPHYR
[74920.791491] usb 1-1: SerialNumber: 373038323236510B
[74920.793837] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

@erwango did you use MCUboot? Because this is the issue here.

@erwango
Copy link
Member

erwango commented Apr 14, 2021

@erwango did you use MCUboot? Because this is the issue here.

@carlescuffi This was an observation vs following message:

@jfischer-no I have test the samples/subsys/usb/cdc_acm application without mcuboot. It's do not works.

@carlescufi carlescufi added the Waiting for response Waiting for author's response label Apr 14, 2021
@carlescufi
Copy link
Member

@wysman is this still an issue? If not please close it.

@jfischer-no
Copy link
Collaborator

Close it since there is no answer and issue is not reproducible.

@Cherish-forever
Copy link

@wysman
I have the same issue, and I found the where the bug:
usb clock in stm32 max is 48MHZ. Change PLL /Q to limit clock to 48MHZ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jfischer-no jfischer-no

@erwango erwango

Labels
area: MCUBoot area: USB Universal Serial Bus bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug Waiting for response Waiting for author's response
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wysman @jfischer-no @carlescufi @nvlsianpu @erwango @Cherish-forever