Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

SPI EasyDMA UB

Đang mở
  • Có gì không ổn?
#2,228 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
cpp
Lĩnh vực
embedded-iot

Hướng nghiên cứu

Bắt đầu tại src/components/ble/DfuService.cpp, quanh dòng 390, và lần theo các thao tác ghi SPI thông qua Spi::Write. Đọc tài liệu Nordic EasyDMA và cuộc thảo luận nrf-hal được liên kết để xác minh những bộ đệm nào hợp lệ trong khi truyền. Công việc được xem là hoàn tất khi đã chọn và triển khai một chiến lược an toàn để xử lý các bộ đệm ghi hằng hoặc nằm trong flash trên các đường dẫn mã bị ảnh hưởng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug maintenance

I was looking into https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/components/ble/DfuService.cpp#L390 and it turns out that the EasyDMA engine cannot read from flash! - See https://docs.nordicsemi.com/bundle/ps_nrf52832/page/easydma.html

Further reading: https://github.com/nrf-rs/nrf-hal/issues/37

There is potential UB across the codebase here - any SPI writes using constant buffers may be stored in flash and therefore be invalid. In particular, all of the display writes may be invalid if the compiler is moving constant arrays to flash (and not copying them to the stack first). Oddly all of the display commands seem to be fine (they clearly work!), while the DFU magic clearly isn't.

I don't know the exact method the compiler uses to decide the storage location. Does anyone know it?
It's certainly affected by constexpr etc.
I might try to analyse the compiler output, but I don't have the tooling to load the binary set up, and it wouldn't be as good as understanding the actual allocation algorithm.

I've got a few ideas here:

  1. Add a check that hard crashes if a flash pointer gets passed into Spi::Write to prevent this from happening in the future
  2. Introduce some kind of blocking write. A lot of these writes are small, but we still don't want to store this data in static RAM. So instead we can load them onto the stack, and then block until the write is complete (won't be waiting long as they are small). We need to wait as data in the stack frame can be overwritten as soon as the function returns by future function's stack frame.
  3. An alternative to (2) would be allocating write buffers on the heap and then the SPI controller freeing them when done. In practice InfiniTime pretty much never runs out of heap, and when it does it usually hangs pretty quickly anyway (LVGL dies).

It looks like the nrf-hal team implemented (1), but only support blocking writes currently.

I'm sure I've missed other good options too, so I'd love any input on this.

Ngôn ngữ chính
C
Star
3.4k
Fork
1.1k
Merge trung bình
23 giờ 18 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của InfiniTimeOrg/InfiniTime

Tất cả issue của InfiniTimeOrg/InfiniTime

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.