Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

rp2pio: background_write(loop=) delivers zero/partial data above ~150 MHz system clock (Metro RP2350)

未关闭
#10,871 9 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
c, python
领域
embedded-iot

调研方向

Start with the implementation of rp2pio.StateMachine.background_write() and trace how its DMA loop restarts; the issue does not name source files or tests. Reproduce the supplied loop=buf case on an RP2350 at 150 MHz and above, then verify that the GPIO output continues to match the buffer across loop restarts.

由索引模型根据 Issue 内容生成。

描述

bug rp235x
CircuitPython version and board name
CircuitPython versions tested: 10.0.3, 10.1.3
  Hardware: Adafruit Metro RP2350 (RP2350B) using A2 stepping (that can have issues)
Code/REPL
import board, rp2pio, adafruit_pioasm, microcontroller, gc, time, digitalio

  microcontroller.cpu.frequency = 252_000_000

  vga_program = adafruit_pioasm.assemble("""
  .program vga_rgb_hsync
  .side_set 1
  .wrap_target
      set y, 15           side 1
  pixel_loop:
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      out pins, 8         side 1 [1]
      jmp y-- pixel_loop  side 1
      nop                 side 1 [7]
      set x, 4            side 0 [15]
  hsync_loop:
      nop                 side 0 [14]
      jmp x-- hsync_loop  side 0
      nop                 side 1 [15]
      nop                 side 1 [15]
      nop                 side 1 [6]
  .wrap
  """)

  # 320x525 frame buffer, all 0xFF (expected output: solid white)
  buf = bytearray([0xFF] * 320 * 525)

  vsync = digitalio.DigitalInOut(board.D11)
  vsync.direction = digitalio.Direction.OUTPUT
  vsync.value = True

  sm = rp2pio.StateMachine(
      vga_program,
      frequency=25_175_000,
      first_out_pin=board.D2,
      out_pin_count=8,
      first_sideset_pin=board.D10,
      sideset_pin_count=1,
      auto_pull=True,
      pull_threshold=8,
      out_shift_right=False,
  )

  sm.background_write(loop=buf)
  time.sleep(0.1)
  print(f"sm.writing: {sm.writing}")  # True
  # GPIO2–9 output: wrong data (see results table below)
Behavior

Expected: GPIO2–9 output matches buf contents (0xFF = solid white).


Results by version and configuration

Config A — v6 PIO: 25.175 MHz SM, out [1] (2 cycles/pixel), 252 MHz CPU:

  ┌─────────┬────────────┬──────────────────────────────────────────────────┐
  │ Version │ sm.writing │                      Screen                      │
  ├─────────┼────────────┼──────────────────────────────────────────────────┤
  │ 10.0.3  │ True       │ All black — zero data delivered                  │
  ├─────────┼────────────┼──────────────────────────────────────────────────┤
  │ 10.1.3  │ True       │ Top ~40% shows partial colour; bottom ~60% black │
  └─────────┴────────────┴──────────────────────────────────────────────────┘

Config B — 252 MHz PIO: 50.4 MHz SM, out [3] (4 cycles/pixel), 252 MHz CPU
(replace frequency=25_175_000 with frequency=50_400_000 and change [1] → [3] in pixel loop):

  ┌─────────┬────────────┬───────────┐
  │ Version │ sm.writing │  Screen   │
  ├─────────┼────────────┼───────────┤
  │ 10.0.3  │ True       │ All black │
  ├─────────┼────────────┼───────────┤
  │ 10.1.3  │ True       │ All black │
  └─────────┴────────────┴───────────┘
Description

StateMachine.background_write(loop=buffer) delivers incorrect pixel data at system clocks ≥ ~160 MHz. DMA reports active (sm.writing=True), HSYNC sideset runs correctly (monitor syncs), but pixel output is wrong. Behavior partially improved in 10.1.3 but is not fixed.

Tested at 200 MHz CPU to rule out other causes:

  ┌─────────────────────────────────────────────┬─────────────────────────────────────────────────┐
  │                    Test                     │                     Result                      │
  ├─────────────────────────────────────────────┼─────────────────────────────────────────────────┤
  │ sm.write(buf) in loop                       │ Completes at ~60 Hz — one-shot DMA works        │
  ├─────────────────────────────────────────────┼─────────────────────────────────────────────────┤
  │ initial_out_pin_state=0xFF, NOP pixel loop  │ Colour visible — GPIO output and PIO clock work │
  ├─────────────────────────────────────────────┼─────────────────────────────────────────────────┤
  │ background_write(loop=buf) with 0xFF buffer │ Sync ✓, pixel data wrong                        │
  └─────────────────────────────────────────────┴─────────────────────────────────────────────────┘

Conclusion: The fault is specifically in background_write's DMA loop restart mechanism. One-shot DMA, GPIO output, and
PIO timing all work correctly at 200 MHz+.


Clock threshold

  ┌───────────┬───────────────────────────┐
  │ CPU clock │          Result           │
  ├───────────┼───────────────────────────┤
  │ 150 MHz   │ Correct ✓                 │
  ├───────────┼───────────────────────────┤
  │ 160 MHz   │ Corrupted / sync unstable │
  ├───────────┼───────────────────────────┤
  │ 200 MHz   │ Sync ✓, wrong data        │
  ├───────────┼───────────────────────────┤
  │ 252 MHz   │ Sync ✓, wrong data        │
  └───────────┴───────────────────────────┘

150 MHz is the rated RP2350B speed; the bug manifests at all tested overclock frequencies.

Additional information

No response

主要语言
C
星标
4.6k
派生
1.4k
平均合并
1 天 8 小时
30 天内合并 PR
155

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

adafruit/circuitpython 的其他 Issue

查看 adafruit/circuitpython 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。