See https://github.com/raspberrypi/pico-setup/issues/57
Clones of debugprobe or invocations of pico-setup.sh frequently
encounter errors relating to bandwidth budgets. These sporadic errors
are due to the large size of the CMSIS_5 repo clone exhausting the
bandwidth quotas on Github, so drop this in favour of a downstream copy
of the relevant CMSIS-DAP firmware files.
Users are advised to delete and regenerate the build directory.
Optionally, reclaim filesystem space by removing .git/modules/CMSIS_5
and all subdirectories.
Point release to address high uart TX baud rate corruption, at the
expense of throughput.
Also skip over an attempt at UART/SDK optimisation that caused issues
for users.
For RX, do burst reads without the SDK wrapper function which checks
the FIFO flags for each read.
For TX, avoid waiting for the FIFO to have space available, which
causes significant thread stalls. Use a slightly pessimistic estimate
of the number of bytes the TX FIFO should consume and only write up to
that number.
Also, there's no point tracking whether or not the scheduler parked the
thread in a call to xTaskDelayUntil - missing a scheduler tick can't be
recovered from.
UART TX corruption has been observed at high baud rates. It seems to be
related to thread preemption when a buffer is pushed to the CDC FIFO
while another task is reading/updating FIFO pointers.
If set to 1x wMaxPacket bytes, the FIFO push only occurs when it is
completely empty. This avoids the bug at the cost of some amount of
throughput, usually 1-2 USB packet times plus inter-packet delay.
This release is a point release because unknown/stale submodule(s)
caused a regression with long UART TX strings that subsequently could
not be reproduced.
The build artifacts for this release were compiled on a Raspberry Pi 5
running Raspberry Pi OS (Debian 12) instead of Ubuntu 22.04 on amd64.
The Pi 5 bootloader will leave devices it doesn't care about in the
Addressed state, so tud_mount_cb never gets called. Handoff from the
bootloader to Linux causes a suspend event followed by Reset.
Check if the interface association was configured on entry to Suspend or
Resume. Also, TinyUSB doesn't expose Bus Reset events for whatever
reason, so there's nothing that tears down the interface threads.
RP2040-E15 can also be triggered if a Debug Probe is connected to a
board with a floating ground. Typically this causes port ESD protection
to temporarily activate, meaning the Dp/Dm state gets corrupted. If this
happens in the middle of a handshake packet, the SIE can lock up.
The only way to detect this case is if SOF_RD stops advancing without a
corresponding suspend interrupt - so add a watchdog thread that forces a
disconnect if the hardware stops reporting frame counts.
This is disruptive, but immediate notification that the probe broke is
preferable to silently failing until the next character is sent by the host.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
We can save more power by parking threads when suspended, and threads
should be deleted when disconnected.
Also fix an inefficiency in usb_thread wakeups when the device is yet to
be configured, but is addressed - slowing down control transfers.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
tud_cdc_connected tests dtr, not rts - so we should do the same.
Don't unconditionally wake the uart thread when set_line_coding happens
- Windows frequently calls this after every linestate change, including
device close.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
- Update CMSIS to 5.7.0
- Update FreeRTOS to downstream commit aa52f214d
Note: for an existing repository clone, you must run
git submodule update --init
and delete and regenerate your build/ directory.
Software typically asserts line break for an extended period
(e.g. PuTTY will assert continuously until the next keypress), so
provide feedback via the LED.
Also declare variables used in both tinyusb callback and uart_thread context
as volatile.
For high data rate applications it's desirable to use hardware flow control
to prevent characters getting dropped when faced with the vagaries of RTOS
and kernel latencies. Adding PROBE_UART_HWFC enables the UART's CTS/RTS pins,
and SET_LINE_STATE messages no longer affect the RTS pin.
* Fix up target reset functionality.
- Correct GPIO direction logic error in `probe_assert_reset`
- Remember to de-assert nRESET on deinit
* board_pico_config: use pin 1 for reset
This pin is normally used for UART debug output, but that is
undocumented. Repurpose it as reset output.
Signed-off-by: Sean Cross <sean@xobs.io>
* main: move stdio_uart_init() before DAP_Setup()
When using GP1 as a reset line, this is necessary to overwrite the
stdio function call from reusing the pin as a debug output.
Signed-off-by: Sean Cross <sean@xobs.io>
---------
Signed-off-by: Sean Cross <sean@xobs.io>
Co-authored-by: Sean Cross <sean@xobs.io>
