zephyrproject-rtos
led_strip: ws2812: led strip does misinterpret the logic level that was set during boot as data bits
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:
Device boot without fix (detailled):
Device boot without delay and reset at init:
@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 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
@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 ?
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] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
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.
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.
@IVandeVeire , can you try this with the latest main
Just checked, the issue is still present on afce5329f772a4306af699c7a06efddf93cadca0 (latest main)
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.
@IVandeVeire There is a configuration on the LPSPI IP to either have the output retain the last value when PCS negated or to have it tristated. The default is the retained (not tristated). I'm not sure why is the value high at first on the mosi line, but maybe having it tristated will have a different effect for this use case. I can make a PR to add a DT property to change this configuration to see if it helps.
@decsny I am a colleague of @IVandeVeire and tested your suggested solution. It seems to fix the issue we had.
@decsny I am a colleague of @IVandeVeire and tested your suggested solution. It seems to fix the issue we had.
That's great! I'll work on getting that PR merged. Sorry this issue took so long to figure out, I was not familiar with lpspi until having the opportunity to be working on it recently