WS2812 driver not work on nRF52833DK

[WolsYang]

Describe the bug
A clear and concise description of what the bug is.
WS2812 driver not work on nRF52833DK

Please also mention any information which could help others to understand
the problem you're facing:
- What target platform are you using?
nRF52833DK
- What have you tried to diagnose or workaround this issue?
Try build 52832 sample code to drive ws2812, and it work.
west build -b nrf52dk_nrf52832 zephyr/samples/drivers/led_ws2812/ --pristine
west flash
Add following line to drivers/spi/spi_nrfx_spim.c
#define CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58 1

To Reproduce
Steps to reproduce the behavior:
1.Cd samples/drivers/led_ws2812/boards
2. Copy nrf52dk_nrf52832.conf and nrf52dk_nrf52832.overlay
3. Paste to same path samples/drivers/led_ws2812/boards , and rename to nrf52833dk_nrf52833.conf and nrf52833dk_nrf52833.overlay
4. $ west build -b nrf52833dk_nrf52833 zephyr/samples/drivers/led_ws2812/ --pristine
5. $ west flash, then ws2812 show wrong color.

Expected behavior
WS2812 keep R G B color cycle.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Logs and console output

Environment (please complete the following information):

• OS: 5.14.0-1011-oem Bluetooth: controller: PHY Update Procedure #11-Ubuntu
• Toolchain Zephyr SDK zephyr-sdk-0.14.1
• Commit SHA or Version used

Additional context
Add any other context that could be relevant to your issue, such as pin setting,
target configuration, ...

[WolsYang]

Here is the video what I do
You can see if dashing 52833 image will cause ws2812 keep flashing wrong color

IMG_5896_out.mp4

.

[mbolivar-nordic]

@WolsYang I can't really see anything in your video, sorry.

A few questions for you that may help you debug:

1. What pins do you have connected on the DK board?
2. Did you verify the color mapping on your WS2812 board? Many WS2812 boards are different. The default configuration for the nRF52-DK board is working for 16x RGB WS2812 chains like https://www.adafruit.com/product/1463. Your board may be different.
3. Did you verify the chain length on your WS2812 board?

[WolsYang]

@mbolivar-nordic Sorry, that video relly bad, I know I'm trying to find an easy way to that others understand.

I just want to show WS2812 example code for 52832 works and 52833 are not, they are both flash on 53833dk.
So, I don't think is hw issue.

west build -b nrf52dk_nrf52832 zephyr/samples/drivers/led_ws2812/ --pristine
west flash // To 53833dk and this is work

west build -b nrf52833dk_nrf52833 zephyr/samples/drivers/led_ws2812/ --pristine
west flash // To 53833dk and this is "not" work

I and Bell have several discussions and tests on Discord :https://discord.com/channels/720317445772017664/883445320812466209/996617182991618094

On there has the scope picture, if do "-b nrf53833dk_nrf58833" the signal became really weird.
And we don't think is a hardware issue, maybe is SDK or compile somewhere wrong.
Because Bell's 53833 .hex works on my 52833dk and my 52833 .hex is not.
Also, My 52833 .hex is not working on Bell's 52833 board too, that is why we think is SDK or compile issue, but I have no idea how can I debug it.
I already try to reinstall zephyr and different computers both windows10 and ubuntu20.

=================================================
-- Application: /home/wols/zephyrproject/zephyr/samples/drivers/led_ws2812
-- Found Python3: /home/wols/zephyrproject/.venv/bin/python3 (found suitable exact version "3.8.10") found components: Interpreter
-- Cache files will be written to: /home/wols/.cache/zephyr
-- Zephyr version: 3.1.99 (/home/wols/zephyrproject/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: nrf52833dk_nrf52833
-- ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found host-tools: zephyr 0.14.1 (/home/wols/zephyr-sdk-0.14.1)
-- Found dtc: /home/wols/zephyr-sdk-0.14.1/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
-- Found toolchain: zephyr 0.14.1 (/home/wols/zephyr-sdk-0.14.1)
-- Found BOARD.dts: /home/wols/zephyrproject/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts
-- Found devicetree overlay: /home/wols/zephyrproject/zephyr/samples/drivers/led_ws2812/boards/nrf52833dk_nrf52833.overlay
-- Generated zephyr.dts: /home/wols/zephyrproject/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/wols/zephyrproject/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /home/wols/zephyrproject/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /home/wols/zephyrproject/build/zephyr/dts.cmake

[mbolivar-nordic]

On there has the scope picture, if do "-b nrf53833dk_nrf58833" the signal became really weird.

I agree that signal is really weird. It should not be possible for the signals to be that close together.

Because Bell's 53833 .hex works on my 52833dk and my 52833 .hex is not.
Also, My 52833 .hex is not working on Bell's 52833 board too, that is why we think is SDK or compile issue, but I have no idea how can I debug it.

I agree this sounds like an installation issue, but I too am not so sure how to proceed.

Maybe you can look at the SPIM registers in Ozone and see if there is anything strange or different in the non-working hex, when you compare with the working hex? Since your hardware is OK, there must be some bad peripheral setup somewhere.

[WolsYang]

Maybe you can look at the SPIM registers in Ozone and see if there is anything strange or different in the non-working hex, when you compare with the working hex? Since your hardware is OK, there must be some bad peripheral setup somewhere.

How can I do that? I'll try it later.

[mbolivar-nordic]

Hi, sorry I missed your comment. If you're not familiar with Ozone setup, you can follow the steps here, choosing the 'Debug with Ozone' option: https://nrfconnect.github.io/vscode-nrf-connect/connect/debug_app.html

Once Ozone has started, you should be able to see the peripheral registers in the user interface, so you can compare SPIM in the working and non-working configurations.

[carlescufi]

Closing due to unresponsiveness from the reporter. Please reopen if it's still an issue.