Skip to content

Teensy 4.1 cannot boot 7.0 #5086

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.

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

Closed
Red-M opened this issue Jul 31, 2021 · 11 comments · Fixed by #5182
Closed

Teensy 4.1 cannot boot 7.0 #5086

Red-M opened this issue Jul 31, 2021 · 11 comments · Fixed by #5182
Assignees
Labels
bug mimxrt10xx iMX RT based boards such as Teensy 4.x
Milestone

Comments

@Red-M
Copy link

Red-M commented Jul 31, 2021

CircuitPython version

7.0.0 alpha 5
7.0.0 alpha 4
7.0.0 alpha 3

6.3.0 Does not have this issue

Code/REPL

No COM/serial presented to OS via USB

Behavior

I flash the mentioned 7.0.0 versions and when I plug the teensy back in, after about 3 minutes, all I get is this USB descriptor:
image

Description

No response

Additional information

No response

@Red-M Red-M added the bug label Jul 31, 2021
@dhalbert dhalbert added this to the 7.0.0 milestone Jul 31, 2021
@dhalbert dhalbert added the mimxrt10xx iMX RT based boards such as Teensy 4.x label Jul 31, 2021
@DavePutz
Copy link
Collaborator

DavePutz commented Jul 31, 2021

I had the same issue on a imxrt1010_evk
A jlink debugger in normal mode had this stack:

#0  port_idle_until_interrupt () at supervisor/port.c:406
#1  0x6002699e in run_code_py (safe_mode=<optimized out>) at ../../main.c:597
#2  main () at ../../main.c:850

Ran in debug mode and got the following stack:

#0  vsnprintf (str=<optimized out>, size=538972849, fmt=<optimized out>, ap=...) at ../../lib/utils/printf.c:119
#1  0x6002794a in reset_cpu () at supervisor/port.c:313
#2  0x6002859c in reset_into_safe_mode (reason=reason@entry=HARD_CRASH) at ../../supervisor/shared/safe_mode.c:127
#3  0x60027aa8 in HardFault_Handler () at supervisor/port.c:443
#4  <signal handler called>
#5  CLOCK_SwitchOsc (osc=kCLOCK_RcOsc) at sdk/devices/MIMXRT1011/drivers/fsl_clock.c:189
#6  0x00001bf0 in flexspi_nor_flash_erase_sector (base=base@entry=0x400a0000, address=1074610176)
    at supervisor/flexspi_nor_flash_ops.c:95
#7  0x00001ae8 in port_internal_flash_flush () at supervisor/internal_flash.c:87
#8  0x6002800c in supervisor_flash_flush () at ../../supervisor/shared/flash.c:136
#9  0x6002c65e in supervisor_flash_read_blocks (
    dest=0x202010a0 <_internal_vfs+128> "Adafruit CircuitPython 7.0.0-alpha.5 on 2021-07-31; IMXRT1010-EVK with IMXRT1011DAE5A\r\n", block=32, num_blocks=1) at supervisor/internal_flash.c:111
#10 0x600268fa in disk_read (pdrv=<optimized out>,
    buff=buff@entry=0x202010a0 <_internal_vfs+128> "Adafruit CircuitPython 7.0.0-alpha.5 on 2021-07-31; IMXRT1010-EVK with IMXRT1011DAE5A\r\n", sector=sector@entry=33, count=count@entry=1) at ../../extmod/vfs_fat_diskio.c:42
#11 0x6004d2e6 in move_window (fs=fs@entry=0x20201064 <_internal_vfs+68>, sector=33) at ../../lib/oofatfs/ff.c:1047
#12 0x6004df9a in dir_find (dp=dp@entry=0x20007da8) at ../../lib/oofatfs/ff.c:2420
#13 0x6004e5c0 in follow_path (dp=dp@entry=0x20007da8, path=path@entry=0x60074524 "boot.py")
    at ../../lib/oofatfs/ff.c:3039
#14 0x6004f018 in f_stat (fs=<optimized out>, path=0x60074524 "boot.py", fno=fno@entry=0x20007de8)
    at ../../lib/oofatfs/ff.c:4470
#15 0x60026344 in fat_vfs_import_stat (vfs_in=<optimized out>, path=<optimized out>) at ../../extmod/vfs_fat.c:37
#16 0x600260a2 in mp_vfs_import_stat (path=<optimized out>) at ../../extmod/vfs.c:115
#17 0x60026de2 in first_existing_file_in_list (filenames=filenames@entry=0x60074538 <boot_py_filenames>)
    at ../../main.c:197
#18 0x60026e92 in maybe_run_list (filenames=filenames@entry=0x60074538 <boot_py_filenames>,
    exec_result=exec_result@entry=0x20007fa4) at ../../main.c:206
#19 0x60027078 in run_boot_py (safe_mode=safe_mode@entry=NO_SAFE_MODE) at ../../main.c:702
#20 0x6002746c in main () at ../../main.c:820

Hope this helps.

@DavePutz
Copy link
Collaborator

DavePutz commented Aug 1, 2021

installed a simple "blink led" code.py on 7.0.0-alpha-5 and can see that the code is running, even though there is no REPL or CIRCUITPY drive.

@tannewt tannewt self-assigned this Aug 12, 2021
@tannewt
Copy link
Member

tannewt commented Aug 12, 2021

I started looking at this today and haven't had a ton of success. It appears #4689 caused an assertion error due to the bulk size of the high speed end point that #4774 fixed. At the #4774 commit it appears to work with CDC only. MSC causes issues similar to what Dave saw above. I don't see this issue on main though.

main as of d294692 seems to run but fails to enumerate even with CDC only:

[ 3979.436193] usb 3-5: unable to read config index 0 descriptor/all
[ 3979.436197] usb 3-5: can't read configurations, error -110
[ 3979.559468] usb 3-5: new high-speed USB device number 46 using xhci_hcd
[ 3984.769525] usb 3-5: device descriptor read/8, error -110
[ 3990.102871] usb 3-5: unable to read config index 0 descriptor/all
[ 3990.102877] usb 3-5: can't read configurations, error -110
[ 3990.102920] usb usb3-port5: unable to enumerate USB device

The cdc_msc example works on the imx rt 1011 at hathach/tinyusb@63f7dfe. I'll keep poking at this.

@tannewt
Copy link
Member

tannewt commented Aug 12, 2021

Twist! I left it while writing this up and it eventually enumerated:

[ 8285.567739] xhci_hcd 0000:06:00.3: Timeout while waiting for setup device command
[ 8285.774389] usb 3-5: device not accepting address 51, error -62
[ 8285.897749] usb 3-5: reset high-speed USB device number 51 using xhci_hcd
[ 8290.901474] xhci_hcd 0000:06:00.3: Timeout while waiting for setup device command
[ 8296.234408] xhci_hcd 0000:06:00.3: Timeout while waiting for setup device command
[ 8296.441062] usb 3-5: device not accepting address 51, error -62
[ 8296.441099] usb 3-5: USB disconnect, device number 51
[ 8296.691073] usb 3-5: new high-speed USB device number 52 using xhci_hcd
[ 8301.244405] usb usb3-port5: Cannot enable. Maybe the USB cable is bad?
[ 8302.138008] usb usb3-port5: Cannot enable. Maybe the USB cable is bad?
[ 8302.138040] usb usb3-port5: attempt power cycle
[ 8303.104950] usb usb3-port5: Cannot enable. Maybe the USB cable is bad?
[ 8303.998003] usb usb3-port5: Cannot enable. Maybe the USB cable is bad?
[ 8303.998038] usb usb3-port5: unable to enumerate USB device
[ 8307.204386] usb 3-5: new high-speed USB device number 56 using xhci_hcd
[ 8312.447800] usb 3-5: unable to read config index 0 descriptor/all
[ 8312.447807] usb 3-5: can't read configurations, error -110
[ 8312.571063] usb 3-5: new high-speed USB device number 57 using xhci_hcd
[ 8317.784463] usb 3-5: unable to read config index 0 descriptor/all
[ 8317.784468] usb 3-5: can't read configurations, error -110
[ 8317.784501] usb usb3-port5: attempt power cycle
[ 8318.187727] usb 3-5: new high-speed USB device number 58 using xhci_hcd
[ 8323.327803] usb 3-5: device descriptor read/8, error -110
[ 8328.661134] usb 3-5: unable to read config index 0 descriptor/all
[ 8328.661141] usb 3-5: can't read configurations, error -110
[ 8328.784400] usb 3-5: new high-speed USB device number 59 using xhci_hcd
[ 8339.114467] usb 3-5: New USB device found, idVendor=239a, idProduct=8078, bcdDevice= 1.00
[ 8339.114471] usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8339.114473] usb 3-5: Product: IMXRT1010-EVK
[ 8339.114474] usb 3-5: Manufacturer: NXP
[ 8339.171748] cdc_acm 3-5:1.0: ttyACM1: USB ACM device

@dhalbert
Copy link
Collaborator

I wonder if the clock accuracy is marginal.

@dhalbert
Copy link
Collaborator

dhalbert commented Aug 13, 2021

(EDIT: see below)

usb_hid does NOT have the fix for HIGHSPEED that the other devices have:

~/repos/circuitpython/shared-module$ ag wmaxpacketsize
usb_midi/__init__.c
131:    0x00, 0x02,  // 68,69 wMaxPacketSize (512)
133:    0x40, 0x00,  // 68,69 wMaxPacketSize (64)
151:    0x00, 0x02,  // 80, 81 wMaxPacketSize (512)
153:    0x40, 0x00,  // 80, 81 wMaxPacketSize (64)

storage/__init__.c
67:    0x00, 0x02,  // 13,14 wMaxPacketSize 512
69:    0x40, 0x00,  // 13,14 wMaxPacketSize 64
80:    0x00, 0x02,  // 20,21 wMaxPacketSize 512
82:    0x40, 0x00,  // 20,21 wMaxPacketSize 64

usb_hid/__init__.c
65:    0x40, 0x00,  // 22,23  wMaxPacketSize 64
73:    0x40, 0x00,  // 29,30 wMaxPacketSize 64

usb_cdc/__init__.c
102:    0x40, 0x00,  // 40, 41 wMaxPacketSize 64
125:    0x00, 0x02,  // 56,57  wMaxPacketSize 512
127:    0x40, 0x00,  // 56,57  wMaxPacketSize 64
138:    0x00, 0x02,  // 63,64 wMaxPacketSize 512
140:    0x40, 0x00,  // 63,64 wMaxPacketSize 64

You or I can try adding that in the morning.

@dhalbert
Copy link
Collaborator

I take back the HID thing. In 6.x, HID endpoint descriptors still had a max length of 64.

@dhalbert dhalbert reopened this Aug 13, 2021
@tannewt
Copy link
Member

tannewt commented Aug 13, 2021

I've ordered a Beagle 480 to sniff the USB HS so I'll pick this up once I get it next week.

@dhalbert
Copy link
Collaborator

If we just turn off high speed for now, can we get these boards working? Would it be worth it to allow people to try them for other things?

@tannewt
Copy link
Member

tannewt commented Aug 13, 2021

I'd rather just wait instead of spending any more time on it. There is plenty of other work to do for 7.0.0.

@tannewt
Copy link
Member

tannewt commented Aug 19, 2021

FYI, I found the issue. The iMX code was sleeping when pending USB actions were queued up. This caused the device to not respond. The interrupt that would have woken from sleep had already occurred.

microdev1 pushed a commit that referenced this issue Aug 21, 2021
There is a race between when we run background tasks and when we
sleep. If an interrupt happens between the two, then we may delay
executing the background task. On some ports we checked this for
TinyUSB already. On iMX RT, we didn't which caused USB issues.
This PR makes it more generic for all background tasks including
USB.

Fixes #5086 and maybe others.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mimxrt10xx iMX RT based boards such as Teensy 4.x
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants