Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WS2812 SPI LED driver with DMA on nrf52 bad SPI data #33505

Closed
clementlgl opened this issue Mar 19, 2021 · 4 comments
Closed

WS2812 SPI LED driver with DMA on nrf52 bad SPI data #33505

clementlgl opened this issue Mar 19, 2021 · 4 comments
Assignees
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug

Comments

@clementlgl
Copy link

Describe the bug
I'm trying to make the WS2812 LED example work on nrf52dk_nrf52832.

WS2812 LED driver does not work properly on nrf52. When I use the SPI DMA driver (nordic,nrf-spi), a low level is maintained on the line for a few µS in the middle of the frame (see diagram below) and the LEDs do not support it.

SPIM

Expected behavior
If I use the standard SPI driver (nrf-spi) the bits are less regular but there is no low level maintained several microseconds in the middle of the frame. And it works 🎉

SPI

I think the problem comes from the SPI driver in DMA mode, have you ever had this problem?

To Reproduce
Steps to reproduce the behavior:

  1. west build -b nrf52dk_nrf52832 -p auto samples/drivers/led_ws2812/
  2. west flash

Impact
The LEDs don't work and using the spi driver without DMA is not a good solution.

Environment

  • OS: Ubuntu 18.04
  • Toolchain zephyr 0.12.3
@clementlgl clementlgl added the bug The issue is a bug, or the PR is fixing a bug label Mar 19, 2021
@galak galak added area: SPI SPI bus platform: nRF Nordic nRFx labels Mar 19, 2021
@peterniebert
Copy link
Contributor

I would defintely say that this is not caused by a bug of zephyr, rather it is a design issue in nRF SOCs

I have observed the same thing some time ago independently in the context of mBed OS. Some not obvious change in the processor state must cause this pause. Or maybe, it is a priority issue on the bus?
You might try to place the buffer in a predefined memory page that is not used by anything else?

Maybe this should be discussed with engineers at devzone?

On the other hand, most WS2812 like LEDs now accept pauses of this dimension so it should not be a problem with modern LEDs. The downside is that reset times are now in the low 100s of us, which may negatively affect the frame rate. So you could still solve the problem by changing to modern LEDs.

@peterniebert
Copy link
Contributor

Reset times:

Take a look here: https://datasheet.lcsc.com/szlcsc/2006151006_Worldsemi-WS2812B-B_C114586.pdf
"RESET time>280μs, it won't cause wrong reset while interruption, its upports the lower frequency and inexpensive MCU."

@clementlgl
Copy link
Author

Thank you @peterniebert,

Indeed I tried with LEDs bought more recently and it works well. My other strip is too old ...

If it's a SOC bug it's a shame but I think we can close this issue. I also use Mbed OS and I will try on it.

Thanks for the link to the WS2812 PDF, I had read it too quickly but I had not thought of an evolution of the WS2812 and that the LEDs of my old strip were old !

Thanks for your help

@carlescufi carlescufi added the priority: low Low impact/importance bug label Mar 23, 2021
@carlescufi
Copy link
Member

Closing this since it doesn't seem to be a Zephyr issue. @anangl please reopen if you think this is an actual bug.

narvalotech added a commit to narvalotech/zephyr that referenced this issue Jan 11, 2023
Add a driver implementation that uses the I2S peripheral.
Based off this blog post:
https://electronut.in/nrf52-i2s-ws2812/

Should help with zephyrproject-rtos#33505, zephyrproject-rtos#29877 and maybe zephyrproject-rtos#47780, as there is no garbage
data at the end of transmissions on nRF52832, and no gaps.

Signed-off-by: Jonathan Rico <[email protected]>
narvalotech added a commit to narvalotech/zephyr that referenced this issue Feb 16, 2023
Add a driver implementation that uses the I2S peripheral.
Based off this blog post:
https://electronut.in/nrf52-i2s-ws2812/

Should help with zephyrproject-rtos#33505, zephyrproject-rtos#29877 and maybe zephyrproject-rtos#47780, as there is no garbage
data at the end of transmissions on nRF52832, and no gaps.

Signed-off-by: Jonathan Rico <[email protected]>
mbolivar-nordic pushed a commit that referenced this issue Feb 24, 2023
Add a driver implementation that uses the I2S peripheral.
Based off this blog post:
https://electronut.in/nrf52-i2s-ws2812/

Should help with #33505, #29877 and maybe #47780, as there is no garbage
data at the end of transmissions on nRF52832, and no gaps.

Signed-off-by: Jonathan Rico <[email protected]>
nordicjm pushed a commit to nordicjm/zephyr that referenced this issue Mar 8, 2023
Add a driver implementation that uses the I2S peripheral.
Based off this blog post:
https://electronut.in/nrf52-i2s-ws2812/

Should help with zephyrproject-rtos#33505, zephyrproject-rtos#29877 and maybe zephyrproject-rtos#47780, as there is no garbage
data at the end of transmissions on nRF52832, and no gaps.

Signed-off-by: Jonathan Rico <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

5 participants