During enumeration, when there are multiple devices attached to the
hub as it's plugged into the Pi Pico, enumeration hangs, because we
get a "status change" callback with value zero. With this patch, we
retry several times on "zero" status change callbacks, until
eventually we succeed.
This is the cheapo hub that exhibits this behavior, but I assume it's
not the only one: https://www.amazon.com/gp/product/B083RQMC7S.
While debugging this, I consulted the implementation in the Linux
kernel. There, hub setup explicitly checks each port individually,
before starting to depend on "status change" interrupts:
https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/hub.c#L1133.
We probably should do something like that here, but it's a much bigger
change.
* update chipidea dcd, remove manual ep_count and use DCCPARAMS to get number of endpoint instead
* add dcd dcache for chipidea
* add cmake for lpc18
* add makefile build for mcx
* use fork of mcu sdk
* fix ci build with nrf
* flash rp2040 with openocd
- change CFG_TUH_ENDPOINT_MAX to 16 (max endpoint pair per device) if
not defined
- change QHD_MAX for EHCI, should be user configurable and more
optimized in the future
While calling tud_cdc_n_get_line_coding, the structure is copied into
the destination.
Dump of assembler code for function tud_cdc_n_get_line_coding:
0x000193f4 <+0>: mov.w r2, #2112 @ 0x840
0x000193f8 <+4>: ldr r3, [pc, #20] @ (0x19410
<tud_cdc_n_get_line_coding+28>)
0x000193fa <+6>: mla r0, r2, r0, r3
=> 0x000193fe <+10>: ldr.w r3, [r0, #6]
0x00019402 <+14>: str r3, [r1, #0]
On some platform (tested on LPC55S28), the address needs to be 4-bytes
aligned. Without this, the address is
(gdb) p &_cdcd_itf.line_coding
$3 = (cdc_line_coding_t *) 0x40100006 <_cdcd_itf+6>
which leads to a HardFault. With this fix
(gdb) p &_cdcd_itf.line_coding
$5 = (cdc_line_coding_t *) 0x40100008 <_cdcd_itf+8>
and the function can be called properly
Signed-off-by: Jean-Baptiste Theou <jb@thing.com>
