#tinyusb
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
Could you please explain the value, I struggle to understand PIPEBUF. It seems that we need to select and configure pipe (PIPESEL, PIPECFG) first, before allocating memory with PIPEBUF. I am ok with not optimal value for now.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
robust walrus
@jolly scroll nice! that sounds really interesting!
jolly scroll
let me make a thread, so i dont spam this up too much...
ah, no thread perms
] lan_run 0
] irq: raw 0x25000039 respecting mask 0x21000000
980.220600 [DWC2:dwc_check_interrupt]: masked HPRT: 0x8
980.234152 [DWC2:dwc_check_interrupt]: Port Enable/Disable Change
USB_HPRT: 0x1008
980.258991 [DWC2:dwc_check_interrupt]: port disabled
USB_HPRT: 0x1000
980.282697 [DWC2:dwc_check_interrupt]: Disconnect Detected Interrupt
980.296322 [DWC2:dwc_irq]: irq time: 88544
] irq: raw 0x4000035 respecting mask 0x4
981.219814 [DWC2:dwc_check_interrupt]: USB_GOTGINT: 0x40000
981.233683 [DWC2:dwc_check_interrupt]: A-Device Timeout Change
981.246713 [DWC2:dwc_irq]: irq time: 38933
so here for example, i pulled the reset pin of the onboard hub/nic low, and it dropped off the bus
robust walrus
it's all good
jolly scroll
] lan_run 1
] irq: raw 0x5000031 respecting mask 0x1000000
1062.745095 [DWC2:dwc_check_interrupt]: masked HPRT: 0x2
1062.758677 [DWC2:dwc_check_interrupt]: Port Connect Detected
1062.771711 [DWC2:dwc_check_interrupt]: a device is connected
1062.786042 [DWC2:dwc_irq]: irq time: 53376
]
]
i then pull reset high, and now the device connected irq fires
]
] dwc_root_reset
] irq: raw 0x5000031 respecting mask 0x1000000
1088.602327 [DWC2:dwc_check_interrupt]: masked HPRT: 0xc
1088.615952 [DWC2:dwc_check_interrupt]: Port Enable/Disable Change
USB_HPRT: 0x100d
1088.641013 [DWC2:dwc_check_interrupt]: port enabled
USB_HPRT: 0x1005
1088.664636 [DWC2:dwc_check_interrupt]: a device is connected
1088.677651 [DWC2:dwc_irq]: irq time: 87775
if i then assert the usb reset signal for 50ms, the port transitions to the enabled state
] addr0_get
...
bLength: 128
bDescriptorType: 0
bcdUSB: 0x5
class: 18 1
protocol: 0
max-packet-size: 2
oh, it seems to be totally corrupt on doing it a second time
bLength: 18
bDescriptorType: 1
bcdUSB: 0x200
class: 9 0
protocol: 2
max-packet-size: 64
if i reboot, and repeat, i now get a valid looking usb hub device descriptor
robust walrus
are you able to capture the usb bus? are you managing any caches between usb memory and cpu memory?
jolly scroll
i'm on a pi2, so the usb bus is just a diff-pair between the SoC and the onboard usb hub
so capturing it would be difficult
dwc2 dma mode doesnt work currently, so everything has to be done thru FIFO's by the cpu
and when running on the VPU, the cache control is managed by bit 30/31 of the addr
currently, everything is going thru the C-alias, raw uncached ram
robust walrus
(I've been wanting to add host support for the pcie connected xhci chip on the rpi sbcs)
jolly scroll
the pi4/pi400 has 2 xhci controllers
robust walrus
its the pi400 in particular I want since I just added usb host support to circuitpython
jolly scroll
the bcm2711 SoC, has both the old dwc2 controller, and a broadcom xhci
both dwc2 and xhci, share a single phy, and only one must be enabled at once
that phy is wired to the usb-c port, so it can only do usb1/usb2
otg_mode=1 routes the PHY to the xhci, and adds it to DT automatically
otg_mode=0 (the default) and the usual dwc2 overlays (like on the pi0) routes it to the dwc, and can do host or device
in addition to all of that, you have the vl805 pcie<->usb xhci controller, for the main 3/4 usb-a ports
jolly scroll
its the pi400 in particular I want since I just added usb host support to circui...
for the pi400, there is a holket MCU with write-once memory, that scans the keyboard matrix, and turns it into a USB HID device, taking up 1 port of the vl805
robust walrus
the pi400's keyboard is connected to the vl805 right?
jolly scroll
yep
robust walrus
👍 sorry to sidetrack you
jolly scroll
the holtek still scans the keyboard while "off"
and deals with the mosfet that turns the main 5v rail on/off
jolly scroll
oh, it seems to be totally corrupt on doing it a second time
this makes me wonder, where is the rx irq...
there it is, bit 4 of GINTSTS, RxFIFO Non-Empty (RxFLvl)
irq: raw 0x4000039 respecting mask 0x10
19.347122 [DWC2:dwc_irq]: irq time: 12106
irq: raw 0x4000039 respecting mask 0x10
19.371715 [DWC2:dwc_irq]: irq time: 12149
yep, when i control-in EP0, it gets stuck in the irq handler, need to ack it and receive data
robust walrus
so you figured it out?
jolly scroll
ive at least found the rx irq
i suspect there is a packet i didnt pop right
and with the rx irq wired up, i can detect them immediately and pop right away
211 if (interrupt_status & BIT(4)) {
212 ack |= BIT(4);
213 logf("RX irq\n");
214 }
at first, i just ack it, so its not stuck in the irq handler
(and print, so i know)
ah, fail
bit 4 is read-only, you cant clear the irq like normal
it clears on its own, once you read the fifo fully
so, i must read the fifo in the irq handler...
robust walrus
generally tinyusb reads state and queues it into its own fifo in the irq handler so that should be fine
jolly scroll
35.198403 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
channel: 0
byte count: 8
PID: 2
packet status: 2
so now, i need to pop 8 bytes from the hw FIFO, move it to a software FIFO on channel 0, and then wake the thread
jolly scroll
generally tinyusb reads state and queues it into its own fifo in the irq handler...
currently, its a 100% custom stack, but i plan to switch to tinyusb at some point
hmmm, what was the aligned malloc func again...
ah, memalign()
so, i memalign() an 8 byte buffer for the device-descriptor, 32bit aligned
because i'm popping 32bits from the dwc fifo, and just writing them to ram, and 32bit writes must be 32bit aligned
i pass that buffer to control_in(), which stores the buffer in a channel-0 struct
jolly scroll
```
35.198403 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
cha...
and this irq handler, then has to fetch channel 0 from the state
pop 8 bytes from the fifo, and write them to channel 0's buffer
jolly scroll
@robust walrus for some more context, every model of rpi has a VPU processor in it
the VPU is a dual-core processor, with 32 x 32bit scalar registers
and 64x64x8bit vector registers
its mostly RISC in design, but the vector opcodes are fairly complex, and the instructions are variable length
pi2 and up runs the VPU at 500mhz
pi0/pi1 i think run the VPU at 250mhz
and functionally, the arm is more of an optional compute co-processor hanging off the side of the SoC design
robust walrus
How deep is the fifo from dwc?
I know the vpu starts first. That was convenient for me with getting cp going bare metal
jolly scroll
there is a large bank of internal ram on the dwc
robust walrus
So it should be able to hold any low level packet
jolly scroll
in device mode, that manages 17 fifo's, 16 IN fifo's (one per ep) and a single shared OUT fifo (all host->device traffic)
so you can queue up traffic on any IN endpoint, and the dwc can answer anything the host asks for
and the dwc can buffer OUT's from the host
in host mode, it only has 3 fifo's
the rx fifo, which is now the IN direction
and the periodic and non-periodic TX fifo's
so the same ram, now gets split across fewer fifo's
GRXFSIZ tells you the size of the rx fifo...
USB_GRXFSIZ: 0x306
which is 0x306 x 32bit
3096 bytes
USB_GNPTXFSIZ: 0x1000306
USB_GNPTXSTS: 0x80100
this is the non-periodic, and periodic tx fifo's, the lower 16bits is the starting addr within the ram
the upper 16bits is the depth, x 32bit
so periodic is 32 bytes??
and non-periodic is 1024 bytes
ah no, USB_GNPTXSTS is the status
HPTXFSIZ is periodic size
USB_HPTXFSIZ: 0x2000406
2048 bytes
jolly scroll
How deep is the fifo from dwc?
so i can see, that the rx fifo starts at 0, and is 0x306 * 32bit in size
the non-periodic fifo starts at 0x306, and is 0x100 * 32bit in size
and the periodic fifo starts at 0x406, and is 0x200 * 32bit in size
these registers are also RW, so you can re-allocate space, based on your needs
and that covers ~6168 bytes of FIFO space
oh, right, and something funky the dwc does
the "push/pop" addr for each fifo, is a whole 4kb wide
so you can use a 32bit load/store based memcpy, and not care about it incrementing the fifo addr
or use external dma bursts, and not care about the addr incrementing
and i think in host mode, reading anything in that whole 4kb*16 block, counts as a POP against the single rx fifo
there is also a 128kb addr range, to let you just read/write the fifo ram directly
bypassing the push/pop regs
its not clear how much ram is actually implemented
jolly scroll
and this irq handler, then has to fetch channel 0 from the state
pop 8 bytes fro...
distraction (outside here) cleared, implemented this, testing...
bLength: 0
bDescriptorType: 112
bcdUSB: 0x5f75
class: 118 112
protocol: 117
max-packet-size: 95
that aint right!
37.038617 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
channel: 0
byte count: 8
PID: 2
packet status: 2
...
37.232129 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x70080
channel: 0
byte count: 8
PID: 2
packet status: 3
status 2, in packet received
status 3, in transfer completed
i wasnt checking that, and was just popping data twice
had similar problems with device mode before
still corrupt, but all 0's now
and i think it wants me to pop on status 2, its corrupt if i pop on 3
16.173940 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
channel: 0
byte count: 8
PID: 2
packet status: 2
IN complete, popping
popped 0x2000112 0xc4110150 0
popped 0x40020009 0xc4110154 4
bLength: 0
bDescriptorType: 1
bcdUSB: 0x200
class: 9 0
protocol: 2
max-packet-size: 64
the values it popped look right
but the values it then printf'd are corrupt, the length is wrong
because i printf'd the wrong buffer
robust walrus
because i printf'd the wrong buffer
that'd do it
jolly scroll
bLength: 18
bDescriptorType: 1
bcdUSB: 0x200
class: 9 0
protocol: 2
max-packet-size: 64
i now get this same reply, every time i fire a control-in to get the dev-descriptor!
progress!
robust walrus
you are very much in the "hcd" layer of tinyusb
jolly scroll
and i havent even added tinyusb to the project yet!
but i now have a working control-in function, that i can just point tinyusb at
along with a decent handling of most of the irq events
is it reasonable to assume, that the IN size will always be wLength bytes, when doing control-in?
robust walrus
I think so
but I haven't really implemented any low level stuff myself. just debugged in there
jolly scroll
the dwc2 controller is also nasty, in many areas
for example, there are a lot of race-proof interrupt registers, where bits will set themselves, and you must write 1 to clear it
so you can just write BIT(4) to ack event 4, and not risk clearing other events
except, there are 2 or 3 control bits in the same register, that control things like port power
so if you just blindly write BIT(4) to the register, you turn power off, and kill the port!
robust walrus
oops!
jolly scroll
and if you blindly |= BIT(4), you ack interrupts you where not aware of
also, the main device vs host mode flag, is in bit 0 of the interrupt status register
but it doesnt trigger an irq
in device mode, you program a packet-count, and byte-count for an endpoint, and then it does the transfers for you
except surprise, EP0 only supports a 1 bit packet-count
if your EP0 data doesnt fit in 1 packet, you must want for the completion irq, and queue the next one in software
and some datasheets dont mention this
so you are left going in circles for a week 😛
also, if the integrated PHY is mis-configured, then usb will 99% work, but silently corrupt all tcp packets
@robust walrus how bald do you think youll be, by the end of such a thing? 😄
jolly scroll
yeah, i go months without touching this, then get the urge to work on it
so, now to turn off some irq debug logging
i get nearly an entire screen full of logs, for a single control-in
]
] addr0_get
USB_GNPTXSTS: 0x80100
USB_GNPTXSTS: 0x10700fe
28.257143 [DWC2:control_in]: SETUP done
28.268389 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
channel: 0
byte count: 8
PID: 2
packet status: 2
IN complete, popping
popped 0x2000112 0xc4110130 0
popped 0x40020009 0xc4110134 4
28.366786 [DWC2:dwc_irq]: irq time: 98398
28.379136 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x70080
channel: 0
byte count: 8
PID: 2
packet status: 3
28.443297 [DWC2:dwc_irq]: irq time: 64162
28.455761 [DWC2:control_in]: IN done
bLength: 18
bDescriptorType: 1
bcdUSB: 0x200
class: 9 0
protocol: 2
max-packet-size: 64
28.629317 [DWC2:dwc_addr0_get_desc]: 100ms later
dumping channel 0
HCCHAR0: 0x108008
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x80000000
HCDMA0: 0xc4189a88
]
thats better, but can still be shrunk more
@robust walrus a control-in, involves a setup token, a data token with 8 bytes
an in token from the host, and a data token with the descriptor from the device
and then an ack, a 0 length packet, is that in or out?
robust walrus
I don't remember off the top of my head. I'd check tinyusb 🙂
jolly scroll
https://beyondlogic.org/usbnutshell/usb4.shtml#Control i think says that its always the reverse of the data stage
so control-in ack's with out
and control-out acks with in
and distractions are back!
also, right now, all of these actions are manual, via a command line
ideally, things like the usb reset, and get-descriptor, should be event driven
jolly scroll
14.579706 [DWC2:control_in]: IN done
channel 0 wants attention
dumping channel 0
HCCHAR0: 0x100008
HCSPLT0: 0x0
HCINT0: 0x21
xfer complete
ack
HCINTMSK0: 0x7ff
HCTSIZ0: 0x20000000
HCDMA0: 0xc4189a88
14.695551 [DWC2:dwc_irq]: irq time: 104640
14.590909 [DWC2:control_in]: 0-length OUT done
bLength: 18
bDescriptorType: 1
bcdUSB: 0x200
class: 9 0
protocol: 2
max-packet-size: 64
the 0-length data-out, immediately gets an ack and xfer-complete irq
so, i have control-in fully implemented, and in theory, i can just switch to set-addr
@robust walrus oh, and you mentioned circuitpython on the pi400, thats baremetal right? are you interested in gfx accel?
i can do this with 0% cpu usage, and only writing about 400 bytes/frame
robust walrus
<@252717193496756235> oh, and you mentioned circuitpython on the pi400, thats ba...
Yup! It’d be fun to tie it into circuit pythons displayio. It’ll be very cool with usb so it is standalone
jolly scroll
at the most basic level, the 2d core on the rpi is basically a sprite-only gpu
you give it a list of sprites
for each sprite, you give:
- the pixel format *rgb/yuv, and bit depth
- the screen XY
- the source wh
- the dest wh (if scaling)
- the addr of the image data in ram (1 to 3 pointers, depending on if its planar)
- the stride (1 to 3 again)
- some misc flags, like alpha, and mirroring
write that entire list to a dedicated chunk of memory
and then write the index for the start, to a main control reg
if you do the control-reg mid-frame, youll get a tear, but thats it
if you modify part of the control-list thats in use, it can malfunction harder, and spit out 1 or 2 junk frames
a vsync irq is available, so you can modify the main control-reg during the blanking period
in my current driver, i do all of the list updating out of irq
and write the index to a global var
the vsync irq handler then copies it to the control reg, on every vsync
and the 2d core can do this for up to 3 displays at once, depending on scene complexity
each display has its own control reg, and they share the display-list memory
https://github.com/librerpi/rpi-open-firmware/blob/master/docs/pixelvalve.txt
VC4 VC6
0x7e206000 pv0(DSI0/DPI) pv0(DSI0/DPI)
0x7e207000 pv1(DSI1/SMI) pv1(DSI1/SMI)
0x7e20a000 pv2(hdmi0)
0x7e216000 pv4(hdmi1)
0x7e807000 pv2(HDMI/VEC)
0x7ec12000 pv3(vec)
for the pi0-pi3 lineup, there are only 3 pixel valves, each hard-wired to a channel on the 2d core
and each hard-wired to 2 output ports, only one from each PV can be active
SMI isnt documented, DSI0 isnt routed to pins
so your only choice is DPI, DSI1, and then HDMI or VEC(ntsc/pal)
bcm2711 is more complex, it has 5 PV's, but only 3 can be in use at once
i think next, i should take my control-in function, and break it up into smaller pieces
in, out, setup
then i can reuse the in/out code, for regular in/out stuff
static void control_in(dwc_host_state_t *state, int channel, int addr, int endpoint, setupData *setup, uint32_t *buffer) {
dwc_send_setup(state, channel, addr, endpoint, setup);
dwc_host_in(state, channel, addr, endpoint, buffer, setup->wLength);
dwc_host_out(state, channel, addr, endpoint, NULL, 0);
}
@robust walrus does this look much better?
now i just need to flesh things out more, multi-packet transfers, and it should be ready for tinyusb
oh, and split transactions are entirely unhandled
and all of the state to keep track of max packet sizes and what device is at each addr
robust walrus
<@252717193496756235> does this look much better?
I'd suggest looking at the existing tinyusb hcd API: https://github.com/hathach/tinyusb/blob/master/src/host/hcd.h
jolly scroll
I'd suggest looking at the existing tinyusb hcd API: https://github.com/hathach/...
ah:
// Submit a transfer, when complete hcd_event_xfer_complete() must be invoked
bool hcd_edpt_xfer(uint8_t rhport, uint8_t dev_addr, uint8_t ep_addr, uint8_t * buffer, uint16_t buflen);
// Submit a special transfer to send 8-byte Setup Packet, when complete hcd_event_xfer_complete() must be invoked
bool hcd_setup_send(uint8_t rhport, uint8_t dev_addr, uint8_t const setup_packet[8]);
looks like i could just map hcd_setup_send to my dwc_send_setup
and then hcd_edpt_xfer to either dwc_host_in or dwc_host_out
then i just have to handle the callbacks, and the basic attach/detatch events?
and thats basically 80-90% of it?
but then how are split transactions handled? i would need to know what speed a device is, and where in the path the speed drops
hcd_devtree_info_t seems to have the relevant info
extern void hcd_devtree_get_info(uint8_t dev_addr, hcd_devtree_info_t* devtree_info);
so, i could maybe cache that when hcd_edpt_open() is called, and also reserve a channel in the dwc
if i do reserve a channel, then i'm limited to 16 endpoints open at once
jolly scroll
ah:
```c
// Submit a transfer, when complete hcd_event_xfer_complete() must be i...
if i dont reserve a channel, then i need to dynamically claim them, every time one of these 2 is called
that all looks fairly simple, and easy to tie in to what ive already got
i'll have to give that a stab tomorrow
jolly scroll
tossed src/tusb.c into my build, and set CFG_TUSB_MCU=OPT_MCU_BCM2835
and it at least compiles and links
but nothing uses it, so linker gc just deleted it all
53 #if CFG_TUH_ENABLED && defined(TUH_OPT_RHPORT)
54 // init host stack CFG_TUSB_RHPORTx_MODE must be defined
55 TU_ASSERT( tuh_init(TUH_OPT_RHPORT) );
56 #endif
but i think TUH_OPT_RHPORT is missing
jolly scroll
@robust walrus getting into tusb_os_custom.h now, and having some confusing compile errors
robust walrus
<@252717193496756235> getting into `tusb_os_custom.h` now, and having some conf...
like what?
jolly scroll
typedef struct mutex {
uint32_t magic;
thread_t *holder;
int count;
wait_queue_t wait;
} mutex_t;
this is the mutex i have
void mutex_init(mutex_t *);
void mutex_destroy(mutex_t *);
status_t mutex_acquire_timeout(mutex_t *, lk_time_t); /* try to acquire the mutex with a timeout value */
status_t mutex_release(mutex_t *);
and all functions act on a pointer to it
typedef mutex_t* osal_mutex_t; is this then the right typedef?
jolly scroll
lib/tinyusb/upstream/src/osal/osal.h:50:33: error: unknown type name ‘osal_mutex_def_t’
#define OSAL_MUTEX_DEF(_name) osal_mutex_def_t _name
and there seems to be 2 types for mutex
typedef struct mutex osal_mutex_def_t, *osal_mutex_t
reading the pico one as an example, there is a , in there that ive not seen before
i'm guessing osal_mutex_def_t is the non-pointer version?
that seems to have made that layer happy
lib/tinyusb/upstream/src/host/usbh.c:41:33: error: expected ‘)’ before numeric constant
#define CFG_TUH_TASK_QUEUE_SZ 16
^
lib/tinyusb/upstream/src/host/usbh.c:222:42: note: in expansion of macro ‘CFG_TUH_TASK_QUEUE_SZ’
OSAL_QUEUE_DEF(usbh_int_set, _usbh_qdef, CFG_TUH_TASK_QUEUE_SZ, hcd_event_t);
^~~~~~~~~~~~~~~~~~~~~
lib/tinyusb/upstream/src/host/usbh.c:223:8: error: unknown type name ‘osal_queue_t’
static osal_queue_t _usbh_q;
now it seems to want a queue
@robust walrus should the queue be a stream of bytes, or a stream of pointers?
robust walrus
I think its bytes
jolly scroll
ah, rewrite time then
ah, but it seems tinyusb provides the fifo for me
i just need to protect it with a spinlock
jolly scroll
./build-vc4-stage2/lib/tinyusb.mod.o: In function `usbh_driver_set_config_complete':
/home/clever/apps/rpi/lk-overlay/lib/tinyusb/upstream/src/host/usbh.c:1080:(.text.usbh_driver_set_config_complete+0x52): relocation truncated to fit: R_VC4_PCREL27_MUL2 against undefined symbol `tuh_mount_cb'
./build-vc4-stage2/lib/tinyusb.mod.o: In function `process_removing_device':
/home/clever/apps/rpi/lk-overlay/lib/tinyusb/upstream/src/host/usbh.c:1080:(.text.tuh_task_ext+0x1ea): relocation truncated to fit: R_VC4_PCREL27_MUL2 against undefined symbol `tuh_umount_cb'
make[1]: *** [make/build.mk:27: build-vc4-stage2/lk.elf] Error 1
make[1]: Leaving directory '/home/clever/apps/rpi/lk-overlay'
make: *** [makefile:34: _top] Error 2
progress!
down to just 1 undefined function
it links!
cpu 0 LOAD: 100.00%, cs 0, pmpts 97, ints 159, tmr ints 99, tmrs 99
cpu 0 LOAD: 100.00%, cs 0, pmpts 99, ints 160, tmr ints 100, tmrs 101
cpu 0 LOAD: 100.00%, cs 0, pmpts 99, ints 161, tmr ints 101, tmrs 101
it is pegging the cpu
4 static void auto_host_entry(const struct app_descriptor *app, void *args) {
5 tusb_init();
6 while (true) {
7 tuh_task();
8 }
9 }
likely because this isnt blocking
@robust walrus i'm guessing its doing nothing, because i dont run any event callbacks, and tinyusb thinks no connect event has occured?
jolly scroll
191 // Called by HCD to notify stack
192 extern void hcd_event_handler(hcd_event_t const* event, bool in_isr);
] lan_run 0
] irq: raw 0x25000029 respecting mask 0x21000000
17.040448 [DWC2:dwc_check_interrupt]: masked HPRT: 0x8
17.054051 [DWC2:dwc_check_interrupt]: Port Enable/Disable Change
USB_HPRT: 0x1008
17.078968 [DWC2:dwc_check_interrupt]: port disabled
USB_HPRT: 0x1000
17.102769 [DWC2:dwc_check_interrupt]: Disconnect Detected Interrupt
ST_CLO: 17116407
Fatal VPU Exception: Misaligned
and kernel panic!
VPU registers:
r0: 0x75757454 r1: 0xffffffff r2: 0x00000000 r3: 0x00000258
r4: 0x0000000c r5: 0x00000000 r6: 0x55557555 r7: 0xffffffff
r8: 0x00001008 r9: 0xc418f3dc r10: 0xc4014190 r11: 0x00000000
r12: 0x0103d1e3 r13: 0x00000000 r14: 0x00001008 r15: 0x7e980440
pc: 0xc4001c1e lr: 0xc400442c sr: 0x20000000
there is a setting for aligning the transmit buffers if you need to
jolly scroll
pc is inside mutex_acquire_timeout()
lr is inside tu_fifo_write()
static uint16_t _tu_fifo_write_n(tu_fifo_t* f, const void * data, uint16_t n, tu_fifo_copy_mode_t copy_mode)
{
if ( n == 0 ) return 0;
_ff_lock(f->mutex_wr);
so this mutex was probably not aligned correctly
c400441a <tu_fifo_write>:
c400441a: a3 03 stm r6-r9,lr,(--sp)
c400441c: 06 40 mov r6,r0
c400441e: 19 40 mov r9,r1
c4004420: 00 23 ld r0,(r0+0xc)
c4004422: 00 80 05 c0 beq r0,0x0,c400442c <tu_fifo_write+0x12>
c4004426: 01 68 not r1,0x0
c4004428: ff 9f f1 eb bl c4001c0a <mutex_acquire_timeout>
f was initially in r0
the value in r0+0xc was loaded into r0
ah wait, wrong fifo write
bool tu_fifo_write(tu_fifo_t* f, const void * data)
{
_ff_lock(f->mutex_wr);
TU_ATTR_ALWAYS_INLINE static inline void _ff_lock(osal_mutex_t mutex)
{
if (mutex) osal_mutex_lock(mutex, OSAL_TIMEOUT_WAIT_FOREVER);
}
ah, that explains the beq
so if the mutex pointer was null, it just doesnt lock
c4001c0a <mutex_acquire_timeout>:
c4001c0a: a1 03 stm r6-r7,lr,(--sp)
c4001c0c: 59 c0 7c cf add sp,sp,-4
c4001c10: 06 40 mov r6,r0
c4001c12: 17 40 mov r7,r1
c4001c14: 00 08 ld r0,(r0)
c4001c16: 40 e9 78 74 75 6d cmp r0,0x6d757478
c4001c1c: 0b 18 beq c4001c32 <mutex_acquire_timeout+0x28>
c4001c1e: 02 e8 d4 ea 00 c4 mov r2,0xc400ead4
so, r0 would be the raw pointer to the mutex
#define MUTEX_MAGIC (0x6D757478) // 'mutx'
typedef struct mutex {
uint32_t magic;
status_t mutex_acquire_timeout(mutex_t *m, lk_time_t timeout) {
DEBUG_ASSERT(m->magic == MUTEX_MAGIC);
and first thing it does, is load the magic# at the start
r0: 0x75757454
r0 was also preserved into r6...
r6: 0x55557555
wut
10.353948 [DWC2:dwc_check_interrupt]: Disconnect Detected Interrupt
osal_mutex_lock(0x55557555, -1)
ST_CLO: 10380314
Fatal VPU Exception: Misaligned
yep, confirmed
bool tu_fifo_write(tu_fifo_t* f, const void * data)
{
_ff_lock(f->mutex_wr);
@robust walrus so, what is responsible for allocating the memory that mutex_wr points to?
TU_ATTR_ALWAYS_INLINE static inline
void tu_fifo_config_mutex(tu_fifo_t *f, osal_mutex_t wr_mutex, osal_mutex_t rd_mutex)
{
f->mutex_wr = wr_mutex;
f->mutex_rd = rd_mutex;
}
this func
bool tu_edpt_stream_init(tu_edpt_stream_t* s, bool is_host, bool is_tx, bool overwritable,
void* ff_buf, uint16_t ff_bufsize, uint8_t* ep_buf, uint16_t ep_bufsize)
{
osal_mutex_t new_mutex = osal_mutex_create(&s->ff_mutex);
and its just using a mutex in the stream
robust walrus
@jolly scroll I'm not quite following. generally everything tinyusb uses itself is statically allocated
jolly scroll
<@204112578425782272> I'm not quite following. generally everything tinyusb uses...
narrowed it down some
its calling lock on a mutex it never created
so the fifo never went thru tu_edpt_stream_init()
is it illegal to send HCD_EVENT_DEVICE_REMOVE when tinyusb believes nothing was attached?
] lan_run 1
] irq: raw 0x5000021 respecting mask 0x1000000
16.472800 [DWC2:dwc_check_interrupt]: masked HPRT: 0x2
16.486334 [DWC2:dwc_check_interrupt]: Port Connect Detected
osal_mutex_lock(0x55557555, -1)
ST_CLO: 16511970
Fatal VPU Exception: Misaligned
i temporarily commented out the removable event, and bumped it, same thing on insertion event
] lan_run 1
] irq: raw 0x5000021 respecting mask 0x1000000
72.801677 [DWC2:dwc_check_interrupt]: masked HPRT: 0x2
72.815220 [DWC2:dwc_check_interrupt]: Port Connect Detected
tu_fifo_write(0x0, 0xc418f5bc)
osal_mutex_lock(0x55557555, -1)
ST_CLO: 72852147
Fatal VPU Exception: Misaligned
aha, because the fifo was null!
tu_fifo_write(0x0, 0xc418f5dc), lr=0xc4003870
c4003862 <hcd_event_handler>:
c4003862: ef 03 stm lr,(--sp)
c4003864: 01 40 mov r1,r0
c4003866: 00 e7 4e 06 01 f8 ld r0,c4013eb4 <_usbh_q>
c400386c: 80 90 15 06 bl c4004496 <tu_fifo_write>
c4003870: 6f 03 ldm pc,(sp++)
static osal_queue_t _usbh_q;
i think this is a pointer, and its been left as null
ah, and tuh_init() should init it
static void auto_host_entry(const struct app_descriptor *app, void *args) {
puts("doing init");
tusb_init();
uhhhh
it no longer panics
but it also doesnt issue a reset to the port
jolly scroll
if ( !osal_queue_receive(_usbh_q, &event, timeout_ms) ) return;
that is aborting out of tuh_task_ext()
so it never processes any events
jolly scroll
oh, my OSAL_QUEUE_DEF is missing things
yep, that did it!
] lan_run 1
39.782533 [DWC2:dwc_check_interrupt]: a device is connected
osal_mutex_lock(0irq: raw 0x5000021 respecting mask 0x1000000
40.418429 [DWC2:dwc_irq]: irq time: 88754
xc401417c, -1)
40.603467 [DWC2:dwc_send_setup]: SETUP done
@robust walrus so, upon connecting a device, tusb now initiates the bus reset for me, and then sends the setup to enumerate
but i'm not firing the HCD_EVENT_XFER_COMPLETE, so it hangs
robust walrus
sounds like its working so far then
jolly scroll
yep
.ff = TU_FIFO_INIT(_name##_buf, _depth, _type, false) \
the problem, was i was missing this line
i had deleted it, when i thought i had to implement my own queue
then i realized, tusb provides its own fifo, and only wants you to wrap it with spinlocks
and i didnt undelete it
so all fifo's in tusb where broken
499 channel_wait_irq(state, channel);
500 logf("SETUP done\n");
so currently, the setup-done message, is printed by this
hmmm, and i dont actually need to ack it from the irq handler
or rather...
@robust walrus should hcd_setup_send() be blocking or async?
robust walrus
I don't know off the top of my head
jolly scroll
currently, its a blocking call, and the thread sleeps, and the irq wakes it
i feel like blocking is bad, because the entire tuh_task hangs
so it cant do anything else, and is stuck with 1 transaction inflight at any time
and the whole fifo stuff, is to not need the ability to wake threads
oh, nice
the 4bit endpointnr, and the 1bit in/out flag, are right next to eachother in the control reg
so the 5bit form that descriptors and tusb use, is already there
hmmm, or not, the shift is wrong, nvm
robust walrus
are you referencing https://github.com/hathach/tinyusb/tree/master/src/portable/synopsys/dwc2 too?
jolly scroll
not currently
i have done baremetal dwc device mode before, with an entirely custom stack
that was somewhat easier, because wireshark+usbmon on the host could snoop
] lan_run 1
channel 0 wants attention
xfer complete
tu_fifo_write(0xc4013450, 0xc418f758), lr=0xc4003962
18.795649 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x50080
channel: 0
byte count: 8
PID: 2
packet status: 2
IN packet, popping
19.003013 [DWC2:dwc_check_interrupt]: RX irq
USB_GRXSTSP: 0x70080
channel: 0
byte count: 8
PID: 2
packet status: 3
the SETUP completed, and then there was an 8 byte IN, for the partial dev desc
USB_GRXSTSP: 0x50000
channel: 0
byte count: 0
PID: 2
packet status: 2
USB_GRXSTSP: 0x70000
channel: 0
byte count: 0
PID: 2
packet status: 3
19.950546 [DWC2:dwc_check_interrupt]: IN complete
something moved 0 bytes that time
need to adjust the logging, now that its getting a lot more chatty
] lan_run 1
43.524700 [DWC2:hcd_edpt_open]:
43.755486 [DWC2:hcd_edpt_xfer]:
44.252193 [DWC2:hcd_edpt_xfer]:
44.670280 [DWC2:hcd_edpt_xfer]:
45.166930 [DWC2:hcd_device_close]:
45.178700 [DWC2:hcd_edpt_open]:
45.201919 [DWC2:hcd_setup_send]:
45.409544 [DWC2:hcd_edpt_xfer]:
45.587326 [DWC2:hcd_edpt_xfer]:
45.655293 [DWC2:hcd_setup_send]:
46.074043 [DWC2:hcd_edpt_xfer]:
46.251873 [DWC2:hcd_edpt_xfer]:
thats definitely something, need to improve that more
12.934628 [DWC2:hcd_setup_send]:
12.957237 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x0, 8, success, true)
12.997064 [DWC2:hcd_edpt_xfer]: (0, 0, IN 0x80, 0xc4013fb4, 8)
13.085732 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
13.204515 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
13.244830 [DWC2:hcd_edpt_xfer]: (0, 0, OUT 0x0, 0x0, 0)
13.259181 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x0, 0, success, true)
13.323812 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x0, 8, success, true)
13.363653 [DWC2:hcd_edpt_xfer]: (0, 0, IN 0x80, 0x0, 0)
13.451725 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
13.570521 [DWC2:dwc_check_interrupt]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
aha, i'm ack'ing transfers twice
16.126109 [DWC2:hcd_edpt_xfer:298]: (0, 0, IN 0x80, 0xc40141b4, 8)
16.215694 [DWC2:dwc_check_interrupt:427]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
16.336404 [DWC2:dwc_check_interrupt:427]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
[0:] USBH DEVICE ATTACH
[0:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
27.718375 [DWC2:hcd_setup_send:268]:
27.730255 [DWC2:dwc_check_interrupt:427]: hcd_event_xfer_complete(0, 0x0, 8, success, true)
on EP 00 with 8 bytes: OK
ah, thats much better
27.781177 [DWC2:hcd_edpt_xfer:298]: (0, 0, IN 0x80, 0xc40153b4, 8)
packet status: 2
27.880904 [DWC2:dwc_check_interrupt:427]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
packet status: 3
28.001404 [DWC2:dwc_check_interrupt:427]: hcd_event_xfer_complete(0, 0x80, 0, success, true)
on EP 80 with 0 bytes: OK
and thats not right
HUB address = 5 is mounted
😮
@robust walrus other then some features/bugs, i think i'm ready to start working towards the next stage...
i would like to have keyboard, mouse, MSD(storage), ethernet(lan9514) all working
and i would like some kind of lsusb like interface, just to be able to debug things
any tips on all that?
jolly scroll
HUB Get Port Status: addr = 5 port = 1
fixed some issues with alignment and int ep's not having the int type
[0:0] Control data:
0000: 12 01 00 02 FF 00 01 40 |.......@|
11.770494 [DWC2:hcd_edpt_xfer:305]: (0, 0, OUT 0x0, 0x0, 0)
11.794516 [DWC2:dwc_host_out:585]: size=0
on EP 00 with 0 bytes: OK
Set Address = 1
[0:0] Set Address: 00 05 01 00 00 00 00 00
unhandled packet status on rx fifo
channel: 0
byte count: 0
PID: 2
packet status: 7
11.944175 [DWC2:dwc_irq:494]: irq time: 52795
on EP 00 with 8 bytes: OK
it is now getting the dev descriptor of the ethernet part of the lan9514
but then set-addr fails with an unexpected error code
jolly scroll
but then set-addr fails with an unexpected error code
ah, race condition, the channel didnt fully finish the previous transfer
jolly scroll
having trouble fixing that, with a 2nd usb device active, its trying to IN the hub interrupt, at the same time as control-in the new addr-0
so it has 2 pending transfers, and using another channel isnt working
USB_GHWCFG2: 0x228ddd50
OtgMode: 0
OtgArch: 2
NumHstChnl: 7
ah, minor surprise there, the hw only supports 8 channels, not 16
but i'm failing on channel 1 and 5...
jolly scroll
aha, i mis-understood how the fifo's work
robust walrus
<@252717193496756235> other then some features/bugs, i think i'm ready to start ...
All of the class level stuff should "just work" see the examples folder for test code.
fallow birchBOT
jolly scroll
All of the class level stuff should "just work" see the examples folder for test...
i assume you mean examples/host/bare_api/src/main.c
and i'll need to mix several of those together, to get keyb/mouse/msd?
robust walrus
i assume you mean `examples/host/bare_api/src/main.c`
and i'll need to mix sever...
bare_api doesn't really do class stuff. the folders next to it should have higher level class examples
jolly scroll
yeah
i'll need to read all of them, find what is useful, and mix them together
and then for a lsusb style debug...
robust walrus
bare api prints the device descriptor
cdc_msc_hid does three different classes at once
jolly scroll
[0:0:0] USBH DEVICE REMOVED
[0:] USBH DEVICE ATTACH
High Speed
[0:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
on EP 00 with 56 bytes: OK
popped 0x2000112 0xc40155b4 0/8
popped 0x40020009 0xc40155b8 4/8
on EP 80 with 8 bytes: OK
[0:0] Control data:
0000: 12 01 00 02 09 00 02 40 |.......@|
on EP 00 with 0 bytes: OK
ok, so i believe that was tusb, finding the hub
Set Address = 5
[0:0] Set Address: 00 05 05 00 00 00 00 00
on EP 00 with 56 bytes: OK
on EP 80 with 0 bytes: OK
[0:5] Open EP0 with Size = 64
Get Device Descriptor
[0:5] Get Descriptor: 80 06 00 01 00 00 12 00
on EP 00 with 56 bytes: OK
popped 0x2000112 0xc40155b4 0/18
popped 0x40020009 0xc40155b8 4/18
popped 0x95140424 0xc40155bc 8/18
popped 0x200 0xc40155c0 12/18
popped 0x71520100 0xc40155c4 16/18
10.785808 [DWC2:dwc_check_interrupt:384]: i 0, bytes_rem 2, word 0x71520100
on EP 80 with 18 bytes: OK
[0:5] Control data:
0000: 12 01 00 02 09 00 02 40 24 04 14 95 00 02 00 00 |.......@$.......|
0010: 00 00 |..|
then is made the hub device 5, and fetched the dev descriptor again
robust walrus
hubs get numbered after the device numbers. so 1-4 for device and then 5+ for hubs by default
jolly scroll
that descriptor, was 4+4+4+4+2 bytes in size
so 0x71520100 contains 2 bytes of the end
and if the buffer was not a multiple of 32bits, i need to write to it 8bits at a time, to finish it off
you mentioned something about alignment?
yeah, looking at those hexdumps, i have a bug there
and i corrupted the bNumberConfigurations
@robust walrus would it be possible, to enforce that all buffers are 32bit aligned, and a multiple of 32bits? then i can just drop this buggy code
for (int i=0; i<bytes_rem; i++) {
bytes_rem--;
}
doh, thats why its buggy, lol
robust walrus
this is what I'm aware of: https://github.com/hathach/tinyusb/blob/master/src/tusb_option.h#L304
it is 4 byte aligned by default
(but maybe the example doesn't do it)
jolly scroll
bare_api and i think hub, have both given me mis-aligned buffers
robust walrus
could be the example code
jolly scroll
popped 0x2000112 0xc40155b4 0/18
popped 0x40020009 0xc40155b8 4/18
popped 0x95140424 0xc40155bc 8/18
popped 0x200 0xc40155c0 12/18
popped 0x71520100 0xc40155c4 16/18
10.913708 [DWC2:dwc_check_interrupt:384]: i 0, bytes_rem 2, word 0x71520100
10.929047 [DWC2:dwc_check_interrupt:384]: i 1, bytes_rem 2, word 0x715201
this time, it wrote the last 2 bytes correctly
[0:5] Control data:
0000: 12 01 00 02 09 00 02 40 24 04 14 95 00 02 00 00 |.......@$.......|
0010: 00 01 |..|
and bNumberConfigurations is no longer a lie!
Get Configuration[0] Descriptor (9 bytes)
[0:5] Get Descriptor: 80 06 00 02 00 00 09 00
on EP 00 with 56 bytes: OK
on EP 80 with 9 bytes: OK
[0:5] Control data:
0000: 09 02 29 00 01 01 00 E0 01 |..)......|
yeah, that looks like a config desc
Get Configuration[0] Descriptor
[0:5] Get Descriptor: 80 06 00 02 00 00 29 00
on EP 00 with 56 bytes: OK
on EP 80 with 41 bytes: OK
[0:5] Control data:
0000: 09 02 29 00 01 01 00 E0 01 09 04 00 00 01 09 00 |..).............|
0010: 01 00 07 05 81 03 01 00 0C 09 04 00 01 01 09 00 |................|
0020: 02 00 07 05 81 03 01 00 0C |.........|
[0:5] Set Configuration: 00 09 01 00 00 00 00 00
on EP 00 with 56 bytes: OK
on EP 80 with 0 bytes: OK
Device configured
HUB set config: itf = 0
[0:5] Class Request: A0 06 00 00 00 00 09 00
on EP 00 with 56 bytes: OK
the hub appears to be configured
HUB Set Feature: PORT_POWER, addr = 5 port = 1
HUB Set Feature: PORT_POWER, addr = 5 port = 2
and its bringing all ports online
HUB address = 5 is mounted
on EP 81 with 1 bytes: OK
HUB xfer callback
Hub Status Change = 0x02
HUB Get Port Status: addr = 5 port = 1
[0:5] Class Request: A3 00 00 00 01 00 04 00
on EP 00 with 56 bytes: OK
and the interrupt endpoint seems to be working
the lan9514 claims a NIC was plugged into port 1
HUB Set Feature: PORT_RESET, addr = 5 port = 1
[0:5] Class Request: 23 03 04 00 01 00 00 00
on EP 00 with 56 bytes: OK
and now the hub should send a reset pulse
on EP 80 with 8 bytes: OK
[0:0] Control data:
0000: 12 01 00 02 FF 00 01 40 |.......@|
28.740650 [DWC2:dwc_check_interrupt:467]: transaction error on channel 0
@robust walrus and now i'm not calling the right callback for this event
jolly scroll
@robust walrus and i'm getting confusing interrupt patterns
tusb asks to send a setup packet
i then get transfer complete + ack
ack
transfer complete
in 3 different interrupts!
oh, wait...
setup
data + 8 bytes?
robust walrus
¯_(ツ)_/¯
jolly scroll
i'm also getting a NAK from the NIC i think
ah no, that looks like the hub
on EP 00 with 0 bytes: OK
Device configured
Queue EP 81 with 1 bytes ...
36.091324 [DWC2:hcd_edpt_xfer:315]: (0, dev 5, IN 0x1, 0xc4015b47, 1)
36.117668 [DWC2:dwc_host_in:603]: type 3, mps 64, addr 5, pid 2, buffer 0xc4015b47
channel 0 wants attention after 2 uSec
dumping channel 0
HCCHAR0: 0xc15c8840
HCSPLT0: 0x0
HCINT0: 0x10
NAK
HCINTMSK0: 0x7ff
HCTSIZ0: 0x80001
HCDMA0: 0x0
36.229418 [DWC2:dwc_check_interrupt:471]: NAK on chan 0
oh, i think i know why
it tried to read an interrupt endpoint, and it had nothing to interrupt about
so it NAK'd
@robust walrus should i tell tinyusb about the NAK, or poll it again after some interval myself?
robust walrus
<@252717193496756235> should i tell tinyusb about the NAK, or poll it again aft...
I know the top layer code doesn't get info about the nak. I'm not sure about the lower layers though. My guess is not...
jolly scroll
and the pico datasheet mentioned the hw can poll for you
so the software never even gets the NAK
so i would guess tusb is expecting that level of inteligence
and the driver should hide the stupid
robust walrus
makes sense to me
jolly scroll
for the moment, i dont care about interrupt endpoints NAK'ing (so no hub hotplug, no key/mouse), so i'll just detect that, not flag the transfer as complete, and slap a // TODO on it
because this error is causing it to panic, and cant enumerate the rest of the bus
jolly scroll
Get Device Descriptor
[0:1] Get Descriptor: 80 06 00 01 00 00 12 00
on EP 80 with 18 bytes: OK
[0:1] Control data:
0000: 12 01 00 02 FF 00 01 40 24 04 00 EC 00 02 00 00 |.......@$.......|
0010: 00 01 |..|
class ff
subclass 00
protocol 1
max-packet 64
24 04 00 EC, vid/pid, bit odd
drivers/net/usb/smsc95xx.c: USB_DEVICE(0x0424, 0xec00),
but the drivers say its right
robust walrus
👍
jolly scroll
32.565864 [DWC2:hcd_edpt_xfer:322]: (0, dev 1, OUT 0x0, 0x0, 0) chan=1
dumping channel 1
HCCHAR1: 0xc0500008
HCSPLT1: 0x0
HCINT1: 0x80
transaction error
HCINTMSK1: 0x7ff
HCTSIZ1: 0x60080000
HCDMA1: 0x0
32.762071 [DWC2:dwc_check_interrupt:488]: transaction error on channel 1
so, if the max-packet size is 64, why did i get an error on control?
i think this is a 0-length out, to ack the control-in
1387 // Get full device descriptor
1388 TU_LOG_USBH("Get Device Descriptor\r\n");
1389 TU_ASSERT(tuh_descriptor_get_device(new_addr, _usbh_ctrl_buf, sizeof(tusb_desc_device_t), process_enumeration, ENUM_GET_9BYTE_CONFIG_DESC), );
1390 }
process_enumeration 1397: ASSERT FAILED
ah, wrong lines
1393 case ENUM_GET_9BYTE_CONFIG_DESC:
1394 {
1395 tusb_desc_device_t const * desc_device = (tusb_desc_device_t const*) _usbh_ctrl_buf;
1396 usbh_device_t* dev = get_device(daddr);
1397 TU_ASSERT(dev, );
process_enumeration() daddr=0 state=3
Get 8 byte of Device Descriptor
process_enumeration() daddr=0 state=7
Set Address = 5
process_enumeration() daddr=0 state=8
Get Device Descriptor
process_enumeration() daddr=5 state=9
after a set-addr call, the callback is still ran with addr 0, as expected
so, state 8(ENUM_GET_DEVICE_DESC) is kinda ran with the wrong daddr, because it just changed
but it all works out
then with the 2nd device that fails...
process_enumeration() daddr=5 state=2
process_enumeration() daddr=5 state=3
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
29.161900 [DWC2:hcd_edpt_xfer:322]: (0, dev 0, OUT 0x0, 0x0, 0) chan=0
29.177310 [DWC2:dwc_check_interrupt:488]: transaction error on channel 0
29.192878 [DWC2:dwc_irq:541]: irq time: 15569
on EP 00 with 0 bytes: OK
process_enumeration() daddr=0 state=7
Set Address = 1
wut
ah, ENUM_HUB_CLEAR_RESET_1=2
and while it claims daddr=5 in the triggering xfer, ENUM_ADDR0_DEVICE_DESC then switches to addr 0
then transitions to ENUM_SET_ADDR
jolly scroll
ok, so the hub port has been reset, and it has queried the dev-desc on port 1
Set Address = 1
[0:0] Set Address: 00 05 01 00 00 00 00 00
29.801776 [DWC2:hcd_setup_send:284]: port 0, addr 0
30.314873 [DWC2:dwc_send_setup:584]: dwc_send_setup(0xc4015e6c, 1, 0, 0, 0xc401579c)
process_enumeration() daddr=0 state=8
and set-address completed successfully
so it should now be in ENUM_GET_DEVICE_DESC state
Get Device Descriptor
[0:1] Get Descriptor: 80 06 00 01 00 00 12 00
31.498097 [DWC2:hcd_setup_send:284]: port 0, addr 1
32.011272 [DWC2:dwc_send_setup:584]: dwc_send_setup(0xc4015e6c, 1, 1, 0, 0xc401579c)
on EP 80 with 18 bytes: OK
[0:1] Control data:
0000: 12 01 00 02 FF 00 01 40 24 04 00 EC 00 02 00 00 |.......@$.......|
0010: 00 01 |..|
and it responds with the dev desc, all good
32.643439 [DWC2:hcd_edpt_xfer:322]: (0, dev 1, OUT 0x0, 0x0, 0) chan=1
32.658816 [DWC2:dwc_host_out:646]: size=0
dumping channel 1
HCCHAR1: 0x508040
HCSPLT1: 0x0
HCINT1: 0x0
HCINTMSK1: 0x7ff
HCTSIZ1: 0x80000000
HCDMA1: 0x0
channel 1 wants attention after 4 uSec
dumping channel 1
HCCHAR1: 0xc0500008
HCSPLT1: 0x0
HCINT1: 0x80
transaction error
HCINTMSK1: 0x7ff
HCTSIZ1: 0x60080000
HCDMA1: 0x0
32.839686 [DWC2:dwc_check_interrupt:488]: transaction error on channel 1
32.854701 [DWC2:dwc_irq:541]: irq time: 110840
on EP 00 with 0 bytes: OK
and it ends, with a transaction error
jolly scroll
facepalm
when changing an 8->64, to increase the max packet size
i changed the wrong 8, the size of a setup packet
so every SETUP packet was configured to be 64 bytes in size
18.994410 [DWC2:hcd_edpt_open:299]: dev 0 EP00 opened
19.007343 [DWC2:hcd_setup_send:283]: HOST0 SETUP 0.00 0xc401499c/8
19.023054 [DWC2:dwc_check_interrupt:502]: hcd_event_xfer_complete(0, 0x0, 8, success, true)
19.039029 [DWC2:dwc_irq:538]: irq time: 15976
19.053048 [DWC2:hcd_edpt_xfer:315]: HOST0 <- 0.80 0xc40149b4/8
19.068046 [DWC2:dwc_check_interrupt:418]: hcd_event_xfer_complete(0, 0x80, 8, success, true)
19.084122 [DWC2:dwc_irq:538]: irq time: 16077
19.098233 [DWC2:hcd_edpt_xfer:318]: HOST0 -> 0.00 0x0/0
19.112703 [DWC2:dwc_check_interrupt:497]: transaction error on channel 0
19.128289 [DWC2:dwc_check_interrupt:499]: hcd_event_xfer_complete(0, 0x0, 0, fail, true)
19.143825 [DWC2:dwc_irq:538]: irq time: 31123
[0:0] Control FAILED, xferred_bytes = 0
80 06 00 01 00 00 08 00
Enumeration attempt 1
so, its detecting a device on port 1 of the hub, turning that on, sending a reset, and then begining to query the dev desc
it successfully got a 8 byte reply, then tried to ACK it with an OUT, and failed
and on every retry, it failed again
robust walrus
making progress!
jolly scroll
making progress!
but hit a bit of a dead-end, with the ack phase of get-descriptor failing every time
@robust walrus do you know if accessing a HS device behind a HS hub (technically, all one chip), is special, or do you just set the addr and it works?
jolly scroll
one thing i notice, i was getting a vid/pid for the ethernet
but now i'm not getting that far
what changed...
robust walrus
<@252717193496756235> do you know if accessing a HS device behind a HS hub (tech...
I haven't done much HS stuff. The tinyusb github discussions is a good place to ask too.
jolly scroll
i can try there tomorrow
only other hack i can think of right now, is to modify tinyusb, so it doesnt enable port 1 of the hub
then it would enable an externally facing port, and i could at least probe it with a device i control (pico/scope)
oh, interesting, https://beyondlogic.org/usbnutshell/usb4.shtml#Control says its a DATA1 in the ack phase
but my code is using MDATA
@robust walrus bam! lol
Device 1: ID 0424:ec00
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 0200
bDeviceClass 255
bDeviceSubClass 0
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x0424
idProduct 0xec00
bcdDevice 0200
iManufacturer 0
iProduct 0
iSerialNumber 0
bNumConfigurations 1
a single bit in just one place, lol
so, the weird part, is how the hub half of the chip, allowed this invalid ack
but the ethernet part of the same chip, didnt!!
i also noticed, i need to keep track of the PID toggling, with the hub interrupt endpoint
so i'll need proper state, per endpoint
robust walrus
could be a tinyusb issue too. host support is pretty new
jolly scroll
with no devices connected (just the internal ethernet), i get 1 reply on the hub status port, and then a NAK
with a webcam on an external port, i get a second reply on the status port, but i messed up the data toggling
so it comes up with a dedicated error for that
i assume EP0 is special, and the SETUP token keeps resetting the toggle order
so ive been able to get away with hard-coding the PID's
but thats all good progress, and i can put more time in tomorrow
robust walrus
nice work!
fallow birchBOT
fallow birchBOT
fallow birchBOT
jolly scroll
Device 1: ID 0424:ec00
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 0200
bDeviceClass 255
bDeviceSubClass 0
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x0424
idProduct 0xec00
bcdDevice 0200
iManufacturer 0
iProduct 0
iSerialNumber 0
bNumConfigurations 1
config descriptor
bLength: 9
bDescriptorType: 2
wTotalLength: 39
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 0xe0
bMaxPower: 1
interface
bLength: 9
bDescriptorType: 4
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 3
bInterfaceClass: 255
bInterfaceSubClass: 0
bInterfaceProtocol: 255
iInterface: 0
endpoint 0
bLength: 7
bDescriptorType: 5
bEndpointAddress: 129
wMaxPacketSize: 512
bInterval: 0
endpoint 1
bLength: 7
bDescriptorType: 5
bEndpointAddress: 2
wMaxPacketSize: 512
bInterval: 0
endpoint 2
bLength: 7
bDescriptorType: 5
bEndpointAddress: 131
wMaxPacketSize: 16
bInterval: 4
@robust walrus and with this, i can now see the full descriptors for all devices, as they attach
jolly scroll
bmAttributes: 2
bmAttributes: 2
bmAttributes: 3
a bit more casting, and i can see the endpoint attributes
lower 2bits is type
bulk, bulk, interrupt
makes sense, bulk in each direction for actual packets, interrupt for interrupts
looks like youll need to detect an incoming packet with interrupt, and then pull it with bulk
ah, interesting, linux is using usb_control_msg() to access various control regs
cmd=USB_VENDOR_REQUEST_WRITE_REGISTER
reqtype=USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_DEVICE
i think i just need to load up usbmon, and spy on things, to get a good idea
jolly scroll
17.265495 [DWC2:hcd_edpt_open:299]: dev 0 EP00 opened root port: 0 hub_addr: 0 hub_port: 0 speed: 2
17.292891 [DWC2:hcd_setup_send:283]: HOST0 SETUP 0.00 0xc401459c/8
17.308015 [DWC2:hcd_edpt_xfer:321]: HOST0 <- 0.80 0xc40145b4/8
17.323505 [DWC2:hcd_edpt_xfer:324]: HOST0 -> 0.00 0x0/0
19.457994 [DWC2:hcd_edpt_xfer:324]: HOST1 -> 1.00 0x0/0
~2.1 seconds, to enumerate, with some of the logging still enabled
and fail if i disable the logging
hub doesnt fully enumerate, if i remove logging
added a 10ms sleep on every transfer, now it works
17.394355 [DWC2:hcd_edpt_open:299]: dev 0 EP00 opened root port: 0 hub_addr: 0 hub_port: 0 speed: 2
18.588454 [DWC2:tuh_mount_cb:21]: Device attached, address = 1
~1.1 sec now
jolly scroll
oops, forgot about my uart refclk, when i tried cranking it to 1,000,000 baud!
the refclk is too slow, need to adjust more divisors
jolly scroll
doh, i had the gfxconsole on the whole time, so prints where extra slow
but they still slow things down enough, to not cause that bug
jolly scroll
17.028167 [DWC2:hcd_edpt_open:305]: dev 5 EP81 opened bLength: 7
bDescriptorType: 5
bEndpointAddress: 0x81
bmAttributes: 3
wMaxPacketSize: 1
bInterval: 12
and with better debug, i can now report this, and now i can see what i have access to, to keep track thats its an interrupt ep
jolly scroll
16.188543 [DWC2:hcd_edpt_xfer:351]: HOST0 <- 5.81 0xc401411b/1 pid:0
16.960768 [DWC2:hcd_edpt_xfer:351]: HOST0 <- 5.81 0xc401411b/1 pid:1
packet status: 5
hmmm, pid handling isnt working right
16.122613 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc401411b/1 pid:0
channel: 0
byte count: 1
PID: 0
packet status: 2
so first, i start the interrupt IN with DATA0
then i get an event that 1 byte has been transfered, and its still DATA0
HCCHAR0: 0x15c8840
mps:64 ep:1 dir1 type:3 mc:1 addr:5
HCSPLT0: 0x0
HCINT0: 0x20
ack
HCINTMSK0: 0x7ff
HCTSIZ0: 0xc0000000
size:0 packets:0 pid:2 ping:1
HCDMA0: 0x0
but now the channel is in DATA1 mode
channel: 0
byte count: 1
PID: 0
packet status: 3
i also get a transfer complete event, that still has DATA0 on it
18.705305 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc401411b/1 pid:1
and a while later, it tries to read the EP again, but with DATA2?!
jolly scroll
16.161292 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:0
16.936092 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:2
16.983842 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:0
17.014021 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:2
17.063989 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:0
17.144614 [DWC2:hcd_edpt_xfer:354]: HOST0 <- 5.81 0xc4013f1b/1 pid:2
that looks like its workin!!
20.476780 [DWC2:hcd_edpt_open:297]: dev 0 EP00 opened root port: 0 hub_addr: 5 hub_port: 4 speed: 0
i can confirm, my mouse usb dongle, is full-speed (both tusb and linux say so)
and with split transactions entirely unhandled, it just
20.504802 [DWC2:dwc_check_interrupt:550]: transaction error on channel 0
fails hard, as expected
if i have a high-speed webcam plugged into port4, i get this:
18.745683 [DWC2:hcd_edpt_open:298]: dev 0 EP00 opened root port: 0 hub_addr: 5 hub_port: 4 speed: 2
18.774829 [DWC2:hcd_setup_send:339]: HOST0 SETUP 0.00 0xc4014b70/8
18.794200 [DWC2:hcd_edpt_xfer:355]: HOST0 <- 0.80 0xc4014b88/8 pid:153
18.800272 [DWC2:dwc_check_interrupt:547]: TODO, NAK
it tries to query the dev descriptor, but fails with NAK
or a NAK packet indicating to the host that the endpoint is working, but temporarily has no data to send.
so i think i just need to try the IN again
same happens even with a 1 second sleep (but only 1 IN attempt), on 2 diff HS devices
jolly scroll
after some trial&error, i found a usb<->sd adapter, that doesnt NAK the first descriptor read
Device 2: ID 14cd:121c
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 0200
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x14cd
idProduct 0x121c
bcdDevice 0200
54.544764 [DWC2:hcd_setup_send:344]: HOST2 SETUP 2.00 0xc4013b70/8
55.561734 [DWC2:hcd_edpt_xfer:361]: HOST2 <- 2.80 0xc4013b88/18 type:0
55.568501 [DWC2:dwc_check_interrupt:567]: TODO, NAK
55.624272 [DWC2:dwc_in_retry:383]: HOST3 <- 2.80 0xc4013b88/18 type:0 RETRY
55.641496 [DWC2:hcd_edpt_xfer:367]: HOST3 -> 2.00 0x0/0
looks like this is working
55.649651 [DWC2:hcd_setup_send:344]: HOST3 SETUP 2.00 0xc4013b70/8
56.666622 [DWC2:hcd_edpt_xfer:361]: HOST3 <- 2.80 0xc4013b88/9 type:0 pid:153
56.673302 [DWC2:dwc_check_interrupt:567]: TODO, NAK
56.728988 [DWC2:dwc_in_retry:383]: HOST4 <- 2.80 0xc4013b88/9 type:0 pid:153 RETRY
56.746127 [DWC2:hcd_edpt_xfer:367]: HOST4 -> 2.00 0x0/0
@robust walrus found a possible bug for upstream
TU_ASSERT(total_len <= CFG_TUH_ENUMERATION_BUFSIZE, );
if any configuration descriptor is over 256 bytes, the enumeration halts, and it doesnt try any other device on the bus
a simple usb webcam was enough to break it
but that is in the tusb_config.h, so the user can increase it
plus, that is over the max-packet-size, so my code also cant read it
jolly scroll
@orchid cobalt ive also been working on rpi dwc host mode over here
ive nearly got interrupt endpoints working, but i dont have split transactions currently, so HS only
orchid cobalt
jolly scroll
if i get dwc host mode working fully, then the open firmware can boot from usb
orchid cobalt
I actually don't know much about it.
jolly scroll
the stock firmware is closed-source, and is required for the dram and arm to even start
orchid cobalt
Yeah, that much I know.
jolly scroll
so if you get rid of the closed-source blobs, the rpi cant even blink an LED
https://github.com/librerpi/lk-overlay and https://github.com/librerpi/rpi-open-firmware are projects to fix that
orchid cobalt
The same is true for virtually all x86 systems, despite some vendor claims to the contrary.
jolly scroll
https://github.com/librerpi/rpi-open-firmware can boot linux on the pi2/pi3, in 32bit mode, with no writable blobs present
(maskrom isnt being counted, read-only)
https://github.com/librerpi/lk-overlay can boot linux on the pi2, and is highly modular, so you can customize many parts
orchid cobalt
Interesting
jolly scroll
but currently, hdmi/camera/h264/mpeg2/vc1 dont work
and usb/network boot arent working, but will be possible
orchid cobalt
Just arriving at the theater to watch Oppenheimer though, so I'll have to look another time.
jolly scroll
usb-host works once linux has booted, and ssh/keyboard/mouse are all good
jolly scroll
Device 2: ID 054c:0243
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 0200
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x054c
idProduct 0x0243
bcdDevice 0100
after working at it all night, i can now detect a usb-stick being hotplugged
interrupt endpoints are semi working, and the NAK bugs are fixed
but interrupt just randomly stopped polling on its own
robust walrus
<@252717193496756235> found a possible bug for upstream
`TU_ASSERT(total_len <= ...
I totally expect you to find bugs. 🙂 The host stack is pretty new
jolly scroll
I totally expect you to find bugs. 🙂 The host stack is pretty new
^ ticket filed
jolly scroll
@robust walrus ive also got enumeration of HS devices and int endpoints stable
i can plug/unplug a HS device repeatedly, and it enumerates each time
but if i connect a LS device, the lack of split transactions causes failures, and a lack of cleanup causes it to run out of channels and the whole stack crashes
robust walrus
interesting! so thats due to the high speed hub in the middle?
jolly scroll
interesting! so thats due to the high speed hub in the middle?
yeah, there is a HS hub soldered to the board
so the dwc is always operating in HS mode (enless you force it to FS only)
so i would have to cripple the entire bus, to avoid split transactions
robust walrus
I wonder how that impacts imx hs
jolly scroll
imx?
robust walrus
imx rt 10xxx
jolly scroll
another mcu/board?
i also need to figure out the whole init sequence
because i'm cheating, and relying on the closed firmware
if i run the PHY init i already have, it just breaks entirely
jolly scroll
nope
robust walrus
kk
jolly scroll
just a bit about xhci
fallow birchBOT
This is still happening for me. The drive is labeled DT101 G2 16GB. Here is a screenshot of the beagle capture:
The OUT transactions to EP 02 are failing but CP is continuing. The IN transactions to EP 81 also fail and when they do, TinyUSB is finding the EP 02 failures a second time. The overlay isn't reset out of the failure state when the error is handled. I think there needs to be a check th...
jolly scroll
reading some more, in slave mode (no dma), the high-speed ping protocol isnt very automated (likely due to low fifo space)
software has to manually send ping's, wait for a good reply, then send the true OUT data
but if in dma mode, you can queue up the data, and enable the ping protocol
and the dwc will ping the endpoint until it gets an ack, then fill its own fifo with dma and move the data
low kindle
Hey guys. I am using adafruit TinyUSB along with fastled. When I am using argb 10 outputs, I do not get any flickering. However, if I add two more outputs which totals out to 12 outputs, I get issues. Interestingly enough this issue is only on the first led on the first pin
For context, I am using rp2040 with 6 20 led strips and 6 27 led strips.
jolly scroll
bInterfaceClass: 8
bInterfaceSubClass: 6
bInterfaceProtocol: 80
iInterface: 0
endpoint 0
bLength: 7
bDescriptorType: 5
bEndpointAddress: 0x81
bmAttributes: 2
wMaxPacketSize: 512
bInterval: 255
endpoint 1
bLength: 7
bDescriptorType: 5
bEndpointAddress: 0x2
bmAttributes: 2
wMaxPacketSize: 512
bInterval: 255
i flipped on the MSC/MSD driver in tinyusb, and then things promptly crashed
i forgot to implement OUT transfers with a non-zero packet size, lol
49.274193 [DWC2:hcd_edpt_xfer:382]: HOST0 -> 2.02 0xc4014cec/31 opep:0xc4113bcc
tinyusb tries to do a 31 byte transfer to EP2
jolly scroll
SCSI Test Unit Ready
36.811522 [DWC2:hcd_edpt_xfer:384]: HOST0 -> 2.02 0xc4015b0c/31 opep:0xc411490c
MSC xfer callback
36.879207 [DWC2:hcd_edpt_xfer:377]: HOST0 <- 2.81 0xc4015b2c/13 opep:0xc41148c8 type:2 pid:153
NAK
37.910083 [DWC2:dwc_in_retry:402]: HOST0 <- 2.81 0xc4015b2c/13 type:2 pid:153 opep:0xc41148c8 RETRY
NAK
37.875216 [DWC2:hcd_edpt_xfer:384]: HOST0 -> 2.02 0xc4015b0c/31 opep:0xc411490c
0x43425355
0x54555342
0x0
0x60000
0x0
0x0
0x0
0x0
the 31 bytes send OUT, before it hung
0x43425355, the MSD signature
0x54555342, a tag on the request?
0x0, transfer size?
0x60000, flags=0, CDB length=6
LUN 0, command 0(test unit ready)
looks valid
cbw->tag = 0x54555342; // TUSB
yep, that looks all right
jolly scroll
same NAK issue on a 2nd drive
fallow birchBOT
fallow birchBOT
jolly scroll
/* Submitted by Ren Bigcren <bigcren.ren@sonymobile.com> */
UNUSUAL_DEV( 0x054c, 0x02a5, 0x0100, 0x0100,
"Sony Corp.",
"MicroVault Flash Drive",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_READ_CAPACITY_16 ),
ack!
robust walrus
```
/* Submitted by Ren Bigcren <bigcren.ren@sonymobile.com> */
UNUSUAL_DEV( 0x...
Where is this from? I wonder if my usb key is on it.
jolly scroll
Where is this from? I wonder if my usb key is on it.
linux source
but i notice, the PID differs, so i have a different problem
robust walrus
👍
jolly scroll
asking on another discord server, if i had sent an invalid scsi command, it would have reported STALL
NAK implies the command was valid, and the device just isnt ready yet
but its never ready, and stays in that state
jolly scroll
after fiddling with the dwc core reset bit, and banging my head into interrupt problems, i now have dwc enumerating with just a custom bootcode.bin and nothing else
all closed-source blobs that could have been helping me, are out of the picture
jolly scroll
@robust walrus something i should get your help with later on
i can give you an rpi binary, and you can snoop what it does to an MSD with the 480, just to double-check if its doing what i we expect it to
jolly scroll
@robust walrus whenever your free, drop this onto a (u)SD card, and boot it on a pi0/pi1/pi2/pi3/pi02
it will print a bunch of debug on both the uart (115200) and the composite/ntsc output
when it hits the end, it will have printed the usb descriptors for the usb-nic, if present
then plug in a MSD device with the 480, and see what the capture caught
ive done most of my debug on a pi2, and confirmed it also works on a pi1, so the whole model range should work
robust walrus
I don't have the time for that unfortunately
jolly scroll
@robust walrus about your circuitpython pio/usb stuff
are the only changes youve done for debug? where you working from the main branch from github?
jolly scroll
ive got a pico and a cut up usb extension, so i'm considering wiring the pio-usb up
jolly scroll
ah, and some more good news
i put the above bootcode.bin onto my usb stick, and OTG'd it into a zero2 (rom is host capable)
SCSI Test Unit Ready
Queue EP 02 with 31 bytes ...
0x43425355
0x54555342
0x0
0x60000
0x0
0x0
0x0
0x0
OK
on EP 02 with 31 bytes: OK
MSC xfer callback
Queue EP 81 with 13 bytes ...
OK
it enumerates and hangs at the same place
so the hub isnt to blame, and i can take over after the rom used dwc
16.239077 [DWC2:dwc_check_interrupt:571]: port enabled at FS
if i plug a pico in BOOTSEL mode in, i get this
and enumeration proceeds all the way down to failing at the same place
robust walrus
<@252717193496756235> about your circuitpython pio/usb stuff
are the only change...
Ya, I believe it is basically main. I can check on monday.
jolly scroll
so, if i connect my severed usb cable to the right pins, and build it, it should just work?
robust walrus
I fixed one issue with checking that host is active when looking for devices but that shouldn't be related
jolly scroll
as much as it worked for you?
robust walrus
I added host usb init to board_init
you can copy that code from the usb_host feather
and I uncommented the console uart config too
jolly scroll
pico, i assume?
robust walrus
same as the folder name inside the board/ dir
jolly scroll
[clever@amd-nixos:~/apps/rpi/circuitpython]$ ls board
ls: cannot access 'board': No such file or directory
ah, found em
ports/raspberrypi/boards/sparkfun_pro_micro_rp2040
ports/raspberrypi/boards/raspberry_pi_pico
ive got both of those
waiting on my cross-compiler to build now
i just had a crazy idea
you mentioned on stream, having co-processors attached over i2c
what if you ran circuitpython on the VPU, and then used the 4 arm cores as a co-processor, as the design originally intended! lol
jolly scroll
[nix-shell:~/apps/rpi/circuitpython/ports/raspberrypi]$ make -j 16 BOARD=raspberry_pi_pico
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
make: *** No rule to make target 'lib/PicoDVI/software/libdvi/dvi.c', needed by 'build-raspberry_pi_pico/genhdr/qstr.split'. Stop.
seems i'm still missing some submodules, despite init'ing them all
fixed that
[nix-shell:~/apps/rpi/circuitpython/ports/raspberrypi]$ make -j 16 BOARD=raspberry_pi_pico
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
Traceback (most recent call last):
File "../../py/maketranslationdata.py", line 30, in <module>
import huffman
ModuleNotFoundError: No module named 'huffman'
python isnt playing nicely, even after installing everything, its missing things
glacial stratus
```
[nix-shell:~/apps/rpi/circuitpython/ports/raspberrypi]$ make -j 16 BOARD=ras...
best place to ask about build problems in #circuitpython-dev . Did you do make fetch-all-submodules at the top level or make fetch-port-submodules in a port/ directory? That will fetch the lib/huffman submodule.
fallow birchBOT
jolly scroll
best place to ask about build problems in <#327298996332658690> . Did you do `ma...
i had done git submodule init/update and i assumed huffman was done by pip
fallow birchBOT
glacial stratus
i had done `git submodule init/update` and i assumed huffman was done by pip
No, it is our own version of huffman. `git submodule init/update works but fetches gigabytes of stuff from certain repos such as the raspberry pi firmware repo. The designated make targets (described here: https://learn.adafruit.com/building-circuitpython/build-circuitpython#fetch-submodules-3141425) use partial clones or shallow clones to save time and space.
jolly scroll
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: ../espressif/esp-idf (modified content)
modified: ../espressif/esp32-camera (modified content)
modified: ../silabs/tools/slc_cli_linux (modified content)
modified: ../stm/st_driver/stm32f4xx_hal_driver (modified content)
modified: ../../shared-module/displayio/Bitmap.c
and interrupting the submodule thing to kill that firmware repo, caused several dirs to be "modified" and empty
have to deinit and init each to fix em
huffman was one of those
jolly scroll
going backwards some, to add dma support
17.335374 [DWC2:hcd_setup_send:372]: HOST0 SETUP 0.00 0xc4015190/8 opep:0xc4114300
dumping channel 0
HCCHAR0: 0x100008
mps:8 ep:0 dir0 type:0 mc:1 addr:0
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x20000008
size:8 packets:0 pid:1 ping:0
HCDMA0: 0xc4015198
dma has advanced by 9 bytes
packets is 0, but bytes is still 8
but i had programmed it for 8 bytes and 1 packet
dumping channel 0
HCCHAR0: 0x100008
mps:8 ep:0 dir0 type:0 mc:1 addr:0
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x60080008
size:8 packets:1 pid:3 ping:0
HCDMA0: 0xc4015190
vs
dumping channel 0
HCCHAR0: 0x100008
mps:8 ep:0 dir0 type:0 mc:1 addr:0
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x20000008
size:8 packets:0 pid:1 ping:0
HCDMA0: 0xc4015198
before and after the enable flag
PID went from SETUP to DATA2, likely to prepare for the next packet
packets 1->0, implying it transmitted one
dma went up by 8, implying it read some
ah, an irq is firing, but its not proceeding to the next stage right
HCINT0: 0x23
xfer complete
halted
ack
yep, perfect, so why did my code not do the right thing
ah, my big else-if block
the halted irq has priority, and does nothing, and blocks all others
ok, SETUP appears to complete
tinyusb then does an 8-byte IN...
it would help if i set the dma dest, lol
and same as before, the interrupts firing differ, so i need to handle that
dma seems implemented, and enumeration works once more
Queue EP 81 with 1 bytes ...
20.461786 [DWC2:hcd_edpt_xfer:393]: HOST0 <- 5.81 0xc4015c3b/1 opep:0xc4114784 type:3 pid:0
Hub Status Change = 0x02
HUB Get Port Status: addr = 5 port = 1
the hub reported a change on a port...
Device configured
Queue EP C1 with 1 bytes ...
24.332040 [DWC2:hcd_edpt_xfer:393]: HOST0 <- 5.c1 0xc4015c3b/1 opep:0xc4114784 type:3 pid:0
and then config was done, so it grabbed an invalid endpoint and resumed querying!!
ah, i think i see the problem
43 typedef struct
44 {
45 uint8_t itf_num;
46 uint8_t ep_in;
47 uint8_t port_count;
48 uint8_t status_change; // data from status change interrupt endpoint
49
50 CFG_TUH_MEM_ALIGN hub_port_status_response_t port_status;
51 CFG_TUH_MEM_ALIGN hub_status_response_t hub_status;
52 } hub_interface_t;
its doing a dma write, directly into line 48
it might round down, to the next 32bit
so, dma splats all over lines 45-48
@robust walrus now what?
jolly scroll
jolly scroll
on EP 00 with 1431655765 bytes: OK
overflow time! 😄
> (1431655765).toString(16)
'55555555'
oh, not even overflow, just undefined
fixed
jolly scroll
Device found: type = Mass storage, addr = 6
Trying booting from MSD device addr 6
Retrieving the config descriptor
Found ep_in = 00000001, ep_out = 00000002
GetMaxLun returned 0, max_lun = 0
Sending and retrying TEST_UNIT_READY
Sending SCSI_COMMAND_INQUIRY
Sending READ_CAPACITY
init_msd returned 0
oh, and i found this in the firmware logs
jolly scroll
confirmed why interrupt endpoints are broken
in PIO mode, each IN turns up in the rx-fifo, and thats where i toggle the PID
in DMA mode, the rx-fifo is dead-silent
fallow birchBOT
frosty abyss
Is tinyusb supported on UART programmers, such as CP2102?
fallow birchBOT
fallow birchBOT
robust walrus
Is tinyusb supported on UART programmers, such as CP2102?
not that I know of. are they reprogrammable?
@jolly scroll I'm back now (was weekending)
jolly scroll
ah, wb
@robust walrus after enabling dma, i had a range of new problems, mostly fixed
status_changein the hub state was not aligned, so a 32bit write trashed the hub state, fixed- interrupts fire in a totally different order, and my handler stopped calling complete callbacks in tinyusb
- my code for IN DATA0/DATA1 toggling relies on the rx-fifo, but DMA just bypasses the rx-fifo entirely, so i have to replace that
also, while reading tinyusb tickets, i had a theory for why MSD is broken
somebody mentioned a 16bit fifo, and the 31 byte commands, and how the final byte isnt written right
and with my 32bit fifo, the same thing might be happening
but with dma, i would expect the hw to deal with that for me
robust walrus
somebody mentioned a 16bit fifo, and the 31 byte commands, and how the final byt...
Got a link to this? I'll take any leads I can get
my next step was to use the saleae to sniff the bus
jolly scroll
i also had an idea, on how to better test your PIO usb stack, just take tinyusb out of the picture temporarily
keep the hcd, but disable tinyusb itself
then manually call something like hcd_setup_send()
verify it sent the right packet on the beagle480
verify the remote rp2040 received the packet
then move to hcd_edpt_xfer() and test IN and OUT the same way
if all 3 functions work in isolation, they should also work together
and test edge cases, like one byte above/below max-packet-size
i can see how you might even tie that into python
robust walrus
I'm not sure I have the patience to get that working in isolation. good idea though
jolly scroll
just dont link tinyusb
provide FFI code in python, to call hcd_setup_send() and hcd_edpt_xfer(), and make hcd_event_xfer_complete() run a python function
with just those ~3 bits, you can then implement the usb stack in python
but rather then implement a proper one, just call them with chunks of hex, from your existing REPL
it could be a good debug tool, for any future usb-host work, on any platform
next thing on my todo list, is to try and fix DATA0/DATA1 toggling, then maybe i'll take another stab at getting circuitpython to build
19.216291 [DWC2:hcd_edpt_xfer:393]: ->>HOST0 <- 5.81 0xc4015e3c/1 opep:0xc4114988 type:3 pid:0
19.224187 [DWC2:dwc_check_interrupt:626]: bytes 0, buflen 1
19.229561 [DWC2:dwc_check_interrupt:627]: hcd_event_xfer_complete(5, 0x81, 1, success, true)
jolly scroll
so currently, i start with a DATA0 expected, for the hub interrupt
22.379937 [DWC2:hcd_edpt_xfer:393]: HOST0 <- 5.81 0xc4015e3c/1 opep:0xc4114988 type:3 pid:0
then i expect a DATA0 again, on the next read! ❌
and because the hub responds with NAK, that doesnt fail asap
] 26.309054 [DWC2:dwc_check_interrupt:634]: HOST0 data toggle error
26.313477 [DWC2:dwc_irq:702]: irq time: 4423
but upon inserting another device, it responds with DATA1, and fails
oh.....
i just realized, i'm entirely ignoring the toggling for OUT's
what happens if my MSD host sends the wrong DATAn for an OUT?
that might be my problem!
robust walrus
¯_(ツ)_/¯
jolly scroll
i can see 3 ways to confirm that
1: just implement it right (logs would show i'm doing the wrong thing)
2: beagle480
3: rp2040 msd, and it should have its own data-toggle exception
ST_CLO: 91245210
Fatal VPU Exception: Zero
VPU registers:
r0: 0x00000001 r1: 0x2000000a r2: 0x2000000a r3: 0xc71fff74
r4: 0xb9c00000 r5: 0xfa000000 r6: 0xc401558c r7: 0xc0080000
r8: 0x00000300 r9: 0x00000001 r10: 0x8000cb60 r11: 0xc0100000
r12: 0x8000cbc0 r13: 0x00c00000 r14: 0xc0020000 r15: 0x00000080
pc: 0xc40025b6 lr: 0xc40025b6 sr: 0x60000000
Exception info (IC0):
src0: 0x00000200 src1: 0x00000000 vaddr: 0x00000000
C: 0x00000000 S: 0x07490740
Exception info (IC1):
src0: 0x00000201 src1: 0x00000000 vaddr: 0x00000000
C: 0x00000000 S: 0x00000000
dump_thread: t 0xc401558c (idle)
state run, priority 0, remaining quantum 5
stack 0x0, stack_size 0, stack_used 0
entry 0x0, arg 0x0, flags 0x11
wait queue 0x0, wait queue ret 0
We are hanging here ...
ive also noticed, this is firing randomly
PC is pointing to the middle of an infinite loop, that just calls arch_idle()
which just calls sleep and returns
i doubt this is a cpu exception, this hw has system and cpu exceptions mixed into the same table
i'll just ignore that for now, and finish the IN toggling
robust walrus
you may get more insight if you have a tinyusb device with logging on
jolly scroll
yeah
but i lack split transaction support, so i cant talk to a rp2040 on the pi2
and the pi0 cant network boot, so i have to swap an SD card on every compile
robust walrus
ah, you need split to do full speed from a high speed hub?
jolly scroll
yep
robust walrus
👍
jolly scroll
but, i suppose i could cheat
i can disable HS in the dwc
then the hub runs at FS
just to iron out the bugs, i'll disable MSC first
then see what it looks like, if i (un)plug devices repeatedly
20.891483 [DWC2:hcd_edpt_xfer:394]: HOST0 <- 5.81 0xc401301c/1 opep:0xc41119b0 type:3 pid:0
20.926699 [DWC2:dwc_check_interrupt:629]: hcd_event_xfer_complete(5, 0x81, 1, success, true)
so we have a DATA0 on the int
24.336893 [DWC2:hcd_edpt_xfer:394]: HOST0 <- 5.81 0xc401301c/1 opep:0xc41119b0 type:3 pid:2
the ethernet has enumerated, so it waits for a DATA1 on the int
59.510570 [DWC2:dwc_check_interrupt:628]: bytes 0, buflen 1, packets: 1, old next_pid: 2
59.518463 [DWC2:dwc_check_interrupt:629]: hcd_event_xfer_complete(5, 0x81, 1, success, true)
and then it gets one
61.627101 [DWC2:hcd_edpt_open:325]: dev 0 EP00 opened root port: 0 hub_addr: 5 hub_port: 2 speed: 2(HS) opep: 0xc4111a88
bLength: 7
bDescriptorType: 5
bEndpointAddress: 0x0
bmAttributes: 0
wMaxPacketSize: 8
bInterval: 0
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
on EP 00 with 0 bytes: OK
panic (caller 0xc4002e6e): timer 0xc4111a98 already in list
PM_WDOG: 0x7e100024
HALT: spinning forever... (reason = 9)
but then it panic's trying to open the MSC
for plain enumeration
jolly scroll
@robust walrus figured out the latest bug
in PIO mode, NAK kills the transaction, i was having to reset the channel, and retry on a timer
IN DMA mode, NAK isnt fatal, and it retries on its own!
jolly scroll
27.470447 [DWC2:hcd_edpt_open:326]: dev 2 EP02 opened root port: 0 hub_addr: 5 hub_port: 3 speed: 2(HS) opep: 0xc4114d50
SCSI Test Unit Ready
28.209798 [DWC2:hcd_edpt_xfer:403]: HOST0 -> 2.02 0xc4016118/31 opep:0xc4114d50 type:2
28.259239 [DWC2:dwc_check_interrupt:635]: bytes 31, buflen 31, packets: -1717986919, old next_pid: 153
28.268347 [DWC2:dwc_check_interrupt:636]: hcd_event_xfer_complete(2, 0x2, 0, success, true)
msch_xfer_cb 331: ASSERT FAILED
its incorrectly reporting that 0 bytes have been transfered
fixed that
26.432308 [DWC2:hcd_edpt_open:326]: dev 2 EP81 opened root port: 0 hub_addr: 5 hub_port: 3 speed: 2(HS) opep: 0xc4114d08
27.333284 [DWC2:hcd_edpt_xfer:396]: HOST0 <- 2.81 0xc4016138/13 opep:0xc4114d08 type:2 pid:153
HCTSIZ0: 0xd
size:13 packets:0 pid:0 ping:0
acking 0x10 (nak)
aha, my 31 byte OUT, was DATA1
even after i fixed the toggle tracking, the out function ignored it, was hard-coded!
changing it to DATA0, i now get a reply
jolly scroll
i think i did it
] bio list
block devices:
usb2_0, size 4009754624, bsize 512, ref 1 (no erase geometry)
i think thats it
] bio dump usb2_0 0 512
0x00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x000001b0: 00 00 00 00 00 00 00 00 38 c1 43 18 00 00 00 21 |........8.C....!
0x000001c0: 03 00 0c 39 12 44 00 08 00 00 00 00 08 00 00 00 |...9.D..........
0x000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.
]
that looks like an MBR!
[root@amd-nixos:~]# hexdump -C /dev/sdc --length 512
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 38 c1 43 18 00 00 00 21 |........8.C....!|
000001c0 03 00 0c 39 12 44 00 08 00 00 00 00 08 00 00 00 |...9.D..........|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
bio list
block devices:
usb2_0, size 4009754624, bsize 512, ref 2 (no erase geometry)
usb2_0p0, size 268435456, bsize 512, ref 1 (no erase geometry)
]
and primary MBR partitions are now supported
jolly scroll
iManufacturer 1 acked 0x20
ASSERT FAILED at (platform/bcm28xx/dwc2/dwc2.c:690): 0
i have a blue MSD, that i think has a 0 byte manufacturer string
my HCD isnt properly handling a zero-length packet on get-string-descriptor
] bio list
block devices:
usb2_0, size 4009754624, bsize 512, ref 2 (no erase geometry)
usb2_0p0, size 268435456, bsize 512, ref 1 (no erase geometry)
usb3_0, size 2002747392, bsize 512, ref 3 (no erase geometry)
usb3_0p0, size 31457280, bsize 512, ref 1 (no erase geometry)
usb3_0p1, size 1817088000, bsize 512, ref 1 (no erase geometry)
if i comment out fetching that, then things do work
fallow birchBOT
jolly scroll
adding in my existing ext2/4 stack now, and hard crash
jolly scroll
ooo
jolly scroll
dumping channel 0: xfer comp
HCCHAR0: 0x988a00
mps:512 ep:1 dir1 type:2 mc:1 addr:2
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x80000000
size:0 packets:0 pid:0 ping:1
HCDMA0: 0x200
why does that say 200??
dumping channel 0: IN init
HCCHAR0: 0x988a00
mps:512 ep:1 dir1 type:2 mc:1 addr:2
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x40080200
size:512 packets:1 pid:2 ping:0
HCDMA0: 0xc4120220
so, the channel was in this state before being enabled
dumping channel 0: xfer comp
HCCHAR0: 0x988a00
mps:512 ep:1 dir1 type:2 mc:1 addr:2
HCSPLT0: 0x0
HCINT0: 0x0
HCINTMSK0: 0x7ff
HCTSIZ0: 0x80000000
size:0 packets:0 pid:0 ping:1
HCDMA0: 0x00000200