search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.62k stars 6.5k forks source link

led_strip: ws2812: led strip does misinterpret the logic level that was set during boot as data bits #66372

Open IVandeVeire opened 10 months ago

IVandeVeire commented 10 months ago

I was asked to create an issue regarding this pr: https://github.com/zephyrproject-rtos/zephyr/pull/66311

I'm developing an application that uses the ws2812 spi driver to control SK6812-EC3210F addressable leds. I'm using a custom mimx-rt1064 board.

I experienced some weird boot behavior of the leds. When the device boots, the bus level of the mosi line get to logic high for certain amout of time before sending the first data on the bus. Because the data bits are directly sent after the boot sequence, the leds do misinterpret the logic level that was set during boot as data bits.

From my understanding, the mosi line keeps the last level that was assigned on the bus when the spi block gets idle. I'm aware that this may be soc specific behaviour.

To prevent the led strip from misinterpreting the logic level that was set during boot as data bits, I added a reset after the initialization of the ws2812 driver (as in https://github.com/zephyrproject-rtos/zephyr/pull/66311 ). I made some captures (of the mosi line) using a logic analyzer to clarify the issue.

Device boot without fix:

not_fixed

Device boot without fix (detailled):

not_fixed_detail

Device boot without delay and reset at init:

fixed
simonguinot commented 10 months ago

@IVandeVeire IIUC the MOSI signal on your mimx-rt1064 board is idle hiigh at reset and becomes (and stays) idle low after setting it low ?

IVandeVeire commented 10 months ago

@IVandeVeire IIUC the MOSI signal on your mimx-rt1064 board is idle hiigh at reset and becomes (and stays) idle low after setting it low ?

Indeed

simonguinot commented 10 months ago

@IVandeVeire did you look at the pinmux configuration on the i.MX RT1064 MCU ? Maybe it is possible to configure the initial state of the MOSI pin ?

github-actions[bot] commented 7 months ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

github-actions[bot] commented 5 months ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

decsny commented 3 months ago

I think this is probably an LPSPI related issue, maybe it needs some kind of command word in initialization, I don't know a reason why miso would be high after reset, is it doing some spi transfers during reset? It could be that the transfer stalled, because by default we stall the transfer during a frame if it is not complete instead of giving a fifo underrun error. If there is some transfers happening during reset for the LEDs, maybe the data frame size was set incorrectly.

github-actions[bot] commented 1 month ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.