Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

SPI EasyDMA UB

Abierto
  • ¿Algo no está bien?
#2,228 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
embedded-iot

Línea de trabajo

Comienza en src/components/ble/DfuService.cpp alrededor de la línea 390 y sigue las escrituras SPI a través de Spi::Write. Lee la documentación de Nordic EasyDMA y la discusión enlazada de nrf-hal para verificar qué búferes son válidos durante las transferencias. La tarea se considera completada cuando se haya seleccionado e implementado una estrategia segura para los búferes de escritura constantes o residentes en flash a lo largo de las rutas de código afectadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
3.4k
Forks
1.1k
Merge medio
23 h 18 min
PR fusionados (30 d)
1

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InfiniTimeOrg/InfiniTime

Todos los issues de InfiniTimeOrg/InfiniTime

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.