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

6.0.0 not working for me on Fomu #3841

Closed
tcal-x opened this issue Dec 17, 2020 · 12 comments
Closed

6.0.0 not working for me on Fomu #3841

tcal-x opened this issue Dec 17, 2020 · 12 comments
Assignees
@xobs
Labels
bug litex
Milestone
Long term

Comments

@tcal-x
Copy link

tcal-x commented Dec 17, 2020 •
edited
Loading

I downloaded adafruit-circuitpython-fomu-en_US-6.0.0.dfu from https://circuitpython.org/board/fomu/ and installed it on Fomu with dfu-util 0.9.

The RGB LED gives a nice pinkish breathe/blink, but no tty device shows up in /dev, neither ttyUSB nor ttyACM.

I've tried with foboot v2.0.3 and v2.0.3-55-ge928b8, two different Fomus (both PVT), with the same results.

Host is Ubuntu 20.04.

dmesg just shows USB disconnect, device number xxx.

adafruit-circuitpython-fomu-en_US-5.3.1.dfu works correctly on the same Fomus.
@tcal-x
Copy link
Author

tcal-x commented Dec 17, 2020

I built circuitpython at tag: 5.4.0-beta.1 (0ba541d49878f8fa62aca7822e8c7d333dd5c2f0, Jun 8 2020) and that did work on Fomu.

@tcal-x
Copy link
Author

tcal-x commented Dec 17, 2020

Commit f232aef7865c4e094f060f9766418f60fb9f86ea (Jun 15, 2020) "supervisor.mk: Compute USB_DEVICES; remove from boards and ports" also WORKS.

@tcal-x
Copy link
Author

tcal-x commented Dec 17, 2020

f61c4e6 (Nov 11, 2020) -- not working
3dfed3c (Jul 24, 2020) -- not working
2d579cc (Jun 26, 2020) -- works

@dhalbert
Copy link
Collaborator

@xobs would you like to take a look at this?

@tannewt tannewt added this to the Long term milestone Dec 22, 2020
@xobs
Copy link
Collaborator

xobs commented Dec 22, 2020

Sure, let me take a look at it this evening.

@xobs
Copy link
Collaborator

xobs commented Dec 24, 2020

I have it hooked up to an EVT board, and it's looking like it's not properly clearing interrupts. In particular, whenever I break into the debugger it's calling CALLBACK_CRITICAL_END; in background_callback.c:57.

@xobs
Copy link
Collaborator

xobs commented Dec 24, 2020

It's leaking stack somehow. Every time an interrupt hits, the stack pointer is moved up by 160 bytes.

@xobs
Copy link
Collaborator

xobs commented Dec 24, 2020

There were two issues at play:

  1. Interrupts were getting re-enabled prior to the handler returning. This happened both in port_get_raw_ticks() and in supervisor_tick().
  2. Some code was placed in the critical path, resulting in timeouts from the USB stack. Notably, a divide or modulo operation was added somewhere along the line

@xobs
Copy link
Collaborator

xobs commented Dec 24, 2020

Github appears to be broken, and can't create a pull request:

image

Please apply xobs@f3e5441 and xobs@2f95cc9 to fix this issue

tannewt pushed a commit that referenced this issue Dec 28, 2020
@xobs
litex: ensure we don't re-enable interrups during ISR
f3e5441 
During an interrupt handler, interrupts are implicitly disabled. They
will be re-enabled when the interrupt handler returns.

Due to some changes that were made, varous calls will re-enable
interrupts after they're finished. Examples of this include calling
`CALLBACK_CRITICAL_END` and getting the number of ticks with
`port_get_raw_ticks()`.

This patch prevents this from happening by doing two things:

1. Use standard calls in `port_get_raw_ticks()` to disable and re-enable
interrupts, preventing nesting issues, and
2. Increase the nesting count inside `isr()`, reflecting the implicit
call that is made by hardware when an interrupt is handled

This helps to address #3841.

Signed-off-by: Sean Cross <sean@xobs.io>
tannewt pushed a commit that referenced this issue Dec 28, 2020
@xobs
litex: move more critical code to RAM
2f95cc9 
The XIP SPI flash on Fomu is slow, which results in certain operations
taking a long time. This becomes a problem for time-critical operations
such as USB.

Move various calls into RAM to improve performance.

This includes the call to __modsi3 and __udivsi3 which are used by the
supervisor handler to determine if periodic callbacks need to be run.

This finishes fixing #3841

Signed-off-by: Sean Cross <sean@xobs.io>
@fancellu
Copy link

Ditto for me, neither 6.1.0 or 6.2.0-beta.1, they get to the end, no errors show, but no rainbow and fomu flashes red, no usb drive appears

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2019 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 1209
Match product ID from file: 5bf0
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=========================] 100%       522288 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

dfu-util -l says

Found DFU: [1209:5bf0] ver=0101, devnum=3, cfg=1, intf=0, path="2-1.4", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3", serial="UNKNOWN"

@tannewt
Copy link
Member

tannewt commented Jan 28, 2021

@xobs can you make a PR now? If you get the unicorn again please share the full url. I get this if I'm on the wrong base branch.

@dhalbert
Copy link
Collaborator

I think this was fixed by #3878 (a long time ago).

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

@xobs xobs

Labels
bug litex
Projects
None yet
Milestone
Long term
Development

No branches or pull requests
5 participants
@tannewt @xobs @dhalbert @fancellu @tcal-x