LED do not work with RP2040 clone

[lucasromeiro]

Hello, i buy one rp2040 fake/clone... but the LED do not work. they not blink any color.

Anyone can help me with this fake/clone rp2040 tiny? the LED do not work.

[HunterCustom]

Clones done normally come with the firmware pre installed

[lucasromeiroTF]

Clones done normally come with the firmware pre installed

In my case it didn't come with firmware. and putting the firmware from here doesn't work, the LED. Is there any way to resolve this?

[Quas7]

Guess, you would have to tell the devs at least, on which rp2040 pins the LED is located for your clone device. Note, that nobody else besides the developers are able to modify this firmware to match your board and I would personally strongly suggest you just get a proper rp2040 board instead as this will be faster and easier imho.

[lucasromeiro]

@Ansem-SoD @brecht6 @Quas7

These clones of the rp2040 tiny are everywhere, I bought several like this without knowing, in different purchases.

Apparently they only got the pins wrong to activate the LEDS. I don't know how to fix this somehow because lids are very important to help find errors in unlocking.

This code was sent by one of the sellers to show that the LED works (he changed the LED pins), were we able to make a correction for this? I suggest using the jumpers present on pins 24 and 25 on the board to signal that it is a fake board and you should use another LED pin if these points are soldered:

from machine import Pin import array, time from machine import Pin import rp2

p24 = Pin(24, Pin.IN, Pin.PULL_UP) print(p24.value())

p25 = Pin(25, Pin.OUT)

Configure the number of WS2812 LEDs.

NUM_LEDS = 1

@rp2.asm_pio( sideset_init=rp2.PIO.OUT_LOW, out_shiftdir=rp2.PIO.SHIFT_LEFT, autopull=True, pull_thresh=24, ) def ws2812():

fmt: off

T1 = 2
T2 = 5
T3 = 3
wrap_target()
label("bitloop")
out(x, 1)               .side(0)    [T3 - 1]
jmp(not_x, "do_zero")   .side(1)    [T1 - 1]
jmp("bitloop")          .side(1)    [T2 - 1]
label("do_zero")
nop()                   .side(0)    [T2 - 1]
wrap()
# fmt: on

Create the StateMachine with the ws2812 program, outputting on Pin(22).

sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(16))

Start the StateMachine, it will wait for data on its FIFO.

sm.active(1)

Display a pattern on the LEDs via an array of LED RGB values.

ar = array.array("I", [0 for _ in range(NUM_LEDS)])

Cycle colours.

for i in range(4 NUM_LEDS): for j in range(NUM_LEDS): r = 100 g = 0 b = 0 ar[j] = g << 16 | r<<8| b sm.put(ar, 8) time.sleep_ms(50) for i in range(4 NUM_LEDS): for j in range(NUM_LEDS): r = 0 g = 100 b = 0 ar[j] = g << 16 | r<<8| b sm.put(ar, 8) time.sleep_ms(50) for i in range(4 NUM_LEDS): for j in range(NUM_LEDS): r = 0 g = 0 b = 100 ar[j] = g << 16 | r<<8| b sm.put(ar, 8) time.sleep_ms(50) for i in range(4 NUM_LEDS): for j in range(NUM_LEDS): r = 100 g = 100 b = 100 ar[j] = g << 16 | r<<8| b sm.put(ar, 8) time.sleep_ms(50) for i in range(4 * NUM_LEDS): for j in range(NUM_LEDS): r = 0 g = 0 b = 0 ar[j] = g << 16 | r<<8| b sm.put(ar, 8) time.sleep_ms(50)

while 1: if p24.value()==0: p25.on() else: p25.off()

[Quas7]

I really wonder, if they got the pins wrong or if something else is off here... but here the bread crums to follow:

from the original picofly code https://github.com/Ansem-SoD/Picofly/blob/main/code/usk/pins.h you will find

#define PIN_LED_PWR_ITSY 16
#define PIN_RGB_MODE_WS 25

and your example code shows:

p25 = Pin(**25,** Pin.OUT)
...
sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(**16**))

As the pinout seems to be identical between zero and tiny, I do not think that pins 15 and 25 are interchanged (although the naming could suggest it) as no tiny would ever work with LED (but tiny is referenced in the picofly-manual).

Are you absolutely sure, that your setup is ok and did you test your LED with a blinky-test?

I would suppose you test with the "C_Blink Firmware" (https://files.waveshare.com/upload/5/58/RP2040-Zero.zip) and follow the explanations provided here to setup everything https://www.waveshare.com/wiki/RP2040-Tiny

If the LED really works with the blinky-example you can change the pins.h in the picofly code and swap 16 <-> 25, compile and test again, if it works. For compiling follow the waveshare setup guide.

[lucasromeiro]

I really wonder, if they got the pins wrong or if something else is off here... but here the bread crums to follow:

from the original picofly code https://github.com/Ansem-SoD/Picofly/blob/main/code/usk/pins.h you will find

#define PIN_LED_PWR_ITSY 16
#define PIN_RGB_MODE_WS 25

and your example code shows:

p25 = Pin(**25,** Pin.OUT)
...
sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(**16**))

As the pinout seems to be identical between zero and tiny, I do not think that pins 15 and 25 are interchanged (although the naming could suggest it) as no tiny would ever work with LED (but tiny is referenced in the picofly-manual).

Are you absolutely sure, that your setup is ok and did you test your LED with a blinky-test?

I would suppose you test with the "C_Blink Firmware" (https://files.waveshare.com/upload/5/58/RP2040-Zero.zip) and follow the explanations provided here to setup everything https://www.waveshare.com/wiki/RP2040-Tiny

If the LED really works with the blinky-example you can change the pins.h in the picofly code and swap 16 <-> 25, compile and test again, if it works. For compiling follow the waveshare setup guide.

As shown in the Python code they sent, it seems that the LED pin is actually swapped. The other links are ok, the board works, only the LED doesn't. How can I follow these steps to change and recompile?

[lucasromeiro]

@Ansem-SoD @brecht6 can u help me to recompile the code to change the pin of LED? I use the Arduino IDE?

[Quas7]

As I never worked with rp2040 up to now I just quickly setup the rp2040 toolchain via https://github.com/raspberrypi/pico-setup-windows out of interest and visual studio code is familiar to me.

I exchanged 16 and 25 in the pins.h for all defines referencing these pins and compiled in "release mode".

This is the result: 231004_firmware_LED_test.zip

Good luck - hope you can iterate from here as I cannot help much more.

P.S. if you compile yourself, make sure you use the "prepare.py" to merge the usk.bin and busk.bin into one firmware.uf2

P.P.S. ... you have to open the folders code/usk and code/busk each seperately in visual studio and use cmake (left bar) to compile each of them. Afterwards the .bin files are run through prepare.py (you might need to adapt the path to the .bin files)

[lucasromeiro]

As I never worked with rp2040 up to now I just quickly setup the rp2040 toolchain via https://github.com/raspberrypi/pico-setup-windows out of interest and visual studio code is familiar to me.

I exchanged 16 and 25 in the pins.h for all defines referencing these pins and compiled in "release mode".

This is the result: 231004_firmware_LED_test.zip

Good luck - hope you can iterate from here as I cannot help much more.

P.S. if you compile yourself, make sure you use the "prepare.py" to merge the usk.bin and busk.bin into one firmware.uf2

P.P.S. ... you have to open the folders code/usk and code/busk each seperately in visual studio and use cmake (left bar) to compile each of them. Afterwards the .bin files are run through prepare.py (you might need to adapt the path to the .bin files)

I think something wrong was done. The LED didn't work. I'm trying to follow the path you told me to try to compile but I can't understand what to do. I tried here for a few hours but I couldn't.

Did we understand correctly what the LED pin would be? Or was the compilation correct?

I appreciate any help

[Quas7]

@lucasromeiro pin 25 and 16 have been exchanged (=swapped) as you suggested above and there is not much that can be done wrong, I think. Uploading worked as well but I currently only have picos without RGB.

All RP2040 board with WS2812 RGB LED have it connected on GPIO 16 and also your pinout as well as example code show exactly that GPIO 16 is used on your board.

You can simply reconfirm this with a multimeter and check on the board, if GPIO16 (that is pin 27, lower right corner) leads to Pin 3 (Data-In pin) of the RGB LED :

https://files.waveshare.com/upload/7/7a/RP2040-Tiny_Schematic.pdf

[Quas7]

I now understood the simple meaning of ITSY, XIAO, PICO, etc. in the pins.h

The ItsyBitsy RP2040 from adafruit is the only exception from the gpio16 for the RGB... they use gpio16 to power the RGB and gpio17 to communicate with it...

So please check, if you have an ITSY clone and gpio17 as well as gpio16 are running to the RGB LED. In this case, the firmware needs to be compiled as the "ITSY" variant. EDIT: I just noticed, that the firmware is clever and auto-detects the board variant it lives on via board_detect.c. So, it might be, that your clone is somehow messing with this auto-detection. Maybe you should post a picture of your clone board. https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/code/usk/board_detect.c

[lucasromeiro]

@Quas7 Apologies for the delay!

I checked with the multimeter and the following occurs on the clone board:

LED pins: DO- Connected to: (apparently connected to nothing, I didn't find anything on the multimeter and the microscope shows this too, images below) GND- Connected to: General board GND DI- Connected to: (GPIO16 pin 27) VCC- Connected to: 3.3v general on the board

[lucasromeiro]

I now understood the simple meaning of ITSY, XIAO, PICO, etc. in the pins.h

The ItsyBitsy RP2040 from adafruit is the only exception from the gpio16 for the RGB... they use gpio16 to power the RGB and gpio17 to communicate with it...

So please check, if you have an ITSY clone and gpio17 as well as gpio16 are running to the RGB LED. In this case, the firmware needs to be compiled as the "ITSY" variant. EDIT: I just noticed, that the firmware is clever and auto-detects the board variant it lives on via board_detect.c. So, it might be, that your clone is somehow messing with this auto-detection. Maybe you should post a picture of your clone board. https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/code/usk/board_detect.c

Can you help me with this information above? You can provide more data if needed.

[Quas7]

So, the Pin config ist correct and is unlikely an issue of the firmware. Can you post a full picture of the board?

[lucasromeiro]

So, the Pin config ist correct and is unlikely an issue of the firmware. Can you post a full picture of the board?

but wouldn't it be gpio 17 that should be connected instead of gpio 16??

Full picture:

[Quas7]

You have a standard rp2040 tiny and the gpio16 is correct. Power is directly coming from 3.3V rail and no gpio17 is needed.

Very unlikely a firmware issue in my opinion but maybe bad hardware (dead led?)

Does the LED blink with any other example code?

Or could it be, that your clone has Micropython installed by the supplier? You might have to nuke the board first to get a clean start: https://github.com/dwelch67/raspberrypi-pico/blob/main/flash_nuke.uf2

And you press and hold the boot-button on the connector-board while connecting the USB cable, right?

[lucasromeiro]

You have a standard rp2040 tiny and the gpio16 is correct. Power is directly coming from 3.3V rail and no gpio17 is needed.

Very unlikely a firmware issue in my opinion but maybe bad hardware (dead led?)

Does the LED blink with any other example code?

Or could it be, that your clone has Micropython installed by the supplier? You might have to nuke the board first to get a clean start: https://github.com/dwelch67/raspberrypi-pico/blob/main/flash_nuke.uf2

And you press and hold the boot-button on the connector-board while connecting the USB cable, right?

@Quas7

When recording (flash_nuke.uf2) I didn't see any changes, was it just recording it? I tried recording him and then recording the official later, nothing changed.

On a forum I was given the idea of recording an older firmware to test and it worked perfectly. I don't understand why it works with older firmware.

[Quas7]

I do not know, what changes were done with different releases. But if am older one works I would guess the board autodetection is confused.

But you seem to have a working solution now by updating after installation with the toolbox.

[lucasromeiro]

I do not know, what changes were done with different releases. But if am older one works I would guess the board autodetection is confused.

But you seem to have a working solution now by updating after installation with the toolbox.

@Quas7 Hasn't something changed in the way the LEDs are activated? so that it is possible to "correct" it to work in a recompilation of the original firm? Could it be the version of the chip they put on the board? I took a photo of a good one and a bad one. on the left is the one with the problematic LED. Doing it with an old firm and then updating is very bad here, because doing it this way on several switches is very laborious.

[Quas7]

There is no clear change history for the commits to trace this back to a code change.

The chip version should not affect this. Looks also more like lot number than revision.

I could try to disable the autodetect feature but as I do not have a Tiny at hand it is a shot in the dark.

Maybe the devs will look into this with the background provided here.

[lucasromeiro]

There is no clear change history for the commits to trace this back to a code change.

The chip version should not affect this. Looks also more like lot number than revision.

I could try to disable the autodetect feature but as I do not have a Tiny at hand it is a shot in the dark.

Maybe the devs will look into this with the background provided here.

If you could be so kind as to disable the automatic detection I would be very grateful and I am willing to test it.

[lucasromeiro]

There is no clear change history for the commits to trace this back to a code change.

The chip version should not affect this. Looks also more like lot number than revision.

I could try to disable the autodetect feature but as I do not have a Tiny at hand it is a shot in the dark.

Maybe the devs will look into this with the background provided here.

@Quas7

Is there a jumper or solder that I can do to correctly identify the board model?

[Quas7]

I do not know, what changes were done with different releases. But if am older one works I would guess the board autodetection is confused.

But you seem to have a working solution now by updating after installation with the toolbox.

[lucasromeiro]

I do not know, what changes were done with different releases. But if am older one works I would guess the board autodetection is confused.

But you seem to have a working solution now by updating after installation with the toolbox.

@Quas7

I understood. The problem is that I unlock several times a day. It would be great to have something functional without having to make it and then update it. There is still the problem of updating and losing the LED function to do some maintenance. Helps a lot. Would you be able to help me remove the automatic detection from the card and I can test here if it worked? Thank you so much.

[Quas7]

I think, I found the issue with the TINY.

@lucasromeiro Please measure resistance between GPIO25 and GND. For the TINY it should be connected to GND according to the schematics and this connection can be cut between the two SMD pads to solve the board detection confusion. If you can confirm, this information should be placed in the guideline PDF to help others. NOTE: you have to check the resistors on the TINY as some clones have 470Ohm instead of 47Ohm (see guideline).

I will document, how the board detection works so somebody else can optimize it maybe later. In short, I think the board detection has to distinguish also the TINY from the WS type of boards to not get fooled.

These are the supported boards from the picofly guide 6.2 https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/PicoFlyGuideV.6.2.pdf

board_detect.c distinguishes these boards https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/code/usk/board_detect.c

BOARD_WS = the default matching RP2040-zero, RP2040-One and RP2040-Tiny (all same pinout but one difference for the TINY!)
BOARD_XO = Seeed XIAO-RP2040
BOARD_IB = Adafruite ItsyBitsy RP2040
BOARD_PI = Pi Pico
BOARD_SQ = ???

Detection is done via detect_by_pull_up() and return value is the inverted read-GPIO boolean. XIAO: set GPIO1 high, read GPIO2 ItsyBitsy: set GPIO3 high, read GPIO2 Pico: set nothing, read GPIO22 WS: set nothing, read GPIO25 SQC: set nothing, read GPIO17

detect_board() tests first for WS and only if WS fails (test_ws() returns a '1') it will run through XIAO, ITSY, PICO and SQC detection.

And here lies the issue with the TINY as it is not detected as a WS board because GPIO25 is tied to GND (GPIO25 = low = NO WS) via a cuttable trace whereas for ZERO the pin is floating and pulled high (GPIO25 = high = WS).

TINY (R12 is not a SMD resistor but a cuttable trace between the two pads, I think)

ZERO as reference

[lucasromeiro]

I think, I found the issue with the TINY.

@lucasromeiro Please measure resistance between GPIO25 and GND. For the TINY it should be connected to GND according to the schematics and this connection can be cut between the two SMD pads to solve the board detection confusion. If you can confirm, this information should be placed in the guideline PDF to help others. NOTE: you have to check the resistors on the TINY as some clones have 470Ohm instead of 47Ohm (see guideline).

I will document, how the board detection works so somebody else can optimize it maybe later. In short, I think the board detection has to distinguish also the TINY from the WS type of boards to not get fooled.

These are the supported boards from the picofly guide 6.2 https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/PicoFlyGuideV.6.2.pdf

board_detect.c distinguishes these boards https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/code/usk/board_detect.c

BOARD_WS = the default matching RP2040-zero, RP2040-One and RP2040-Tiny (all same pinout but one difference for the TINY!)
BOARD_XO = Seeed XIAO-RP2040
BOARD_IB = Adafruite ItsyBitsy RP2040
BOARD_PI = Pi Pico
BOARD_SQ = ???

Detection is done via detect_by_pull_up() and return value is the inverted read-GPIO boolean. XIAO: set GPIO1 high, read GPIO2 ItsyBitsy: set GPIO3 high, read GPIO2 Pico: set nothing, read GPIO22 WS: set nothing, read GPIO25 SQC: set nothing, read GPIO17

detect_board() tests first for WS and only if WS fails (test_ws() returns a '1') it will run through XIAO, ITSY, PICO and SQC detection.

And here lies the issue with the TINY as it is not detected as a WS board because GPIO25 is tied to GND (GPIO25 = low = NO WS) via a cuttable trace whereas for ZERO the pin is floating and pulled high (GPIO25 = high = WS).

TINY (R12 is not a SMD resistor but a cuttable trace between the two pads, I think)

ZERO as reference

@Quas7

I took the measurement you instructed me, from pin 25 to GND there is 540 ohms. The pads were not connected, I connected pin 25 with GND, but nothing changed. I don't know if I understood correctly or if it said something in my test, I believe I did as explained.

[Quas7]

@lucasromeiro just to be clear on what you measured - you found 540 Ohm between GPIO25 and GND as shown in this figure?

Please check directly at the RP2040 chip, if PIN 37 (GPIO25) is really connected with 540 Ohm to GND.

Also check on another board, in case something has been toasted in the RP2040 chip. Because there is no 540 Ohm resistor in the BOM of the Tiny base design (https://www.waveshare.com/w/upload/7/7a/RP2040-Tiny_Schematic.pdf)

You will have to find this 540 Ohm resistor on the board and remove it to make things work.

Fast alternative would be, if you just cut the trace to PIN37 (GPIO25) right next to the chip:

[Quas7]

And last action for today... "board_WS" for TINY and ZERO firmware 2.73 without board autodetection: 230610_firmware_2.73_board_WS.uf2.zip

[lucasromeiro]

@Quas7 You understood correctly, there is a resistance of 540 ohm between the GPIO25 pin and GND! But I believe this was an error, I got another new board and this resistance no longer existed.

I did the tests you suggested, cut the track close to pin37 and nothing changed. I tried putting the stock firmware and nothing changed. I tried to put the firmware you sent last and it didn't work either. Finally, to validate that the LED was not burned out, I installed firmware 2.67 and the LED worked.

This is all very strange, it seems like we are looking in the wrong place...

@Ansem-SoD @brecht6 can help us? Please

[Quas7]

Floating GPIO25 is perfect - the autodetect should detect it as a WS board.

I ordered one TINY to see this for myself although it could well be, that my version will work perfectly fine.

One other thing could be, that the LED is not genuine a WS2312B and somewhen the WS2312 code was updated and that made it incompatible with your LED. It could well be, that the code for the WS2812 was done differently in the older firmware and the new PIO-based solution is the issue here. But the history does not go far enough back to check on this: https://github.com/Ansem-SoD/Picofly/commits/main/code/usk/ws2812.pio

At least your LED does not look like a "WS2312B" original(?)

yours

You could try to find some "better" WS2312B on some LED-strips, if you have any and solder one to the board.

And one more shot in the dark... I reduced the CLK frequency for the LED to 50% in this firmware (all else standard). 230610_firmware_2.73_400kCLK_WS2812.uf2.zip

And also this sounds VERY similar to the issue here... https://www.particle.io/blog/heads-up-ws2812b-neopixels-are-about-to-change/

Old & New chips are exactly the same as in Timing, Data transmission and Data structure. However, 
the Reset Time increased from >50us to >280us. It won’t cause wrong reset while interruption, 
and what’s more, it supports the lower frequency and inexpensive MCU. When the “Reset Time<280us”, 
don’t mixed up and kindly please make necessary amends.

According to WorldSemi, the new WS2812B NeoPixels have a longer required reset interval, 
up to 280us from 50us.

This is the kicker that tripped us up. One of our products, the 
[Internet Button](https://store.particle.io/products/internet-button) for the Particle Photon, 
includes 11 WS2812B LEDs arranged in a circular display alongside an accelerometer, magnetic buzzer, 
and 4 click buttons as a prototyping platform for simple IoT applications.

While completing quality assurance testing on the manufacturing line, our tried and true test firmware 
was suddenly failing to illuminate the NeoPixels on our factory fresh Internet Buttons. Why? 
Our test firmware included a reset delay of only 10us, well below the new 280us minimum. 
As a result, we had to update our test firmware as well as Internet Button and NeoPixel firmware libraries 
to accommodate the new minimum reset delay.

In other words, the new WS2812B NeoPixels, which carry the same part number as the old ones, 
may cause breaking changes to the behavior of your project. According to the release, 
this change will affect all new WS2812B parts produced by WorldSemi.

That is the reset timing required for the new version (smaller WS2812B asic as seen on your board):

Here is the firmware code, I think is relevant for the reset timing: https://github.com/Ansem-SoD/Picofly/blob/cc1099d6e9f659425b132fc73b9153fe07d605f8/code/usk/misc.c#L107-L133 Changing sleep_us(50) to sleep_us(300) in line 130 should be the reset timing. EDIT: the sleep_us(50) is just the time required to send the bit stream with 800kHz to the LED with some margin - it is not the reset time.

Here is the firmware with this change to test: 230610_firmware_2.73_300us_LED-Reset.uf2.zip

[lucasromeiro]

@Quas7

Hello!! Good news!

With the firn (230610_firmware_2.73_300us_LED-Reset.uf2.zip) the led blinks, but in diferent mode:

https://github.com/Ansem-SoD/Picofly/assets/2086543/12e01023-bb18-469c-8601-09e5a26d3c6e

but, the firm (230610_firmware_2.73_400kCLK_WS2812.uf2.zip) do not have any change

apparently there is a wrong mix of colors, the green seems to always be on. I think the path has been found!!! Now I imagine it's adjusting the delay to match the colors.

[Quas7]

Ah, very good. Green is at the begining of the 24-bit data frame, so there might be some hickup on the first bit, that puts green on 50% output?

Without a scope trace or better logic analyzer trace of the DI pin it is not easy to debug, I think. But let us try to mix 50% clock speed with 300us reset timing: 231006_firmware_2.73_400kCLK_300us_Reset.uf2.zip

[Quas7]

Today a few ZEROs arrived and I checked the LED behavior with all firmware variants and reset timings... ALL worked the same... but guess what, the chip looks very different to your version.

ZERO:

TINY:

I think, your clone has also a cloned LED chip and this is why it behaves erratic. Without a datasheet for the LED chip, there is only trial and error and maybe never a perfect solution as more timings than just the reset timing is required to change (and that is beyond what I want to dive into).

Here is another shot with setting a wait-time of 300us between the LED-init and the LED-data being send with 50% clk speed and 300us rest time. 231006_firmware_2.73_400kCLK_300us_Reset_300us_post-init.uf2.zip

[lucasromeiro]

@Quas7

Hello, yesterday I had an event all day and I couldn't test. I just did the tests and in the two software programs you sent me above, the LED is white with a pink tone and does not blink.

The best firmware so far is the one in the video I gave you. The only downside is that the green LED is always on, which makes it difficult to see the blinks. If you remove the green light that lights up all the time, it will be great to see the blinks.

[Quas7]

@Quas7

Hello, yesterday I had an event all day and I couldn't test. I just did the tests and in the two software programs you sent me above, the LED is white with a pink tone and does not blink.

The best firmware so far is the one in the video I gave you. The only downside is that the green LED is always on, which makes it difficult to see the blinks. If you remove the green light that lights up all the time, it will be great to see the blinks.

Unfortunately, there is no code that activates the "green" on purpose that I could change. The green seems to be a result of a communication issue because of a bad LED clone version. If the other options made it worse, I have not many further ideas what to change.

One last idea is to go the other way and make reset even longer and the frequency higher. I will compile the variants later for testing.

[lucasromeiro]

@Quas7

Cool, I'm available to test.

[Quas7]

I googled a bit around at it seems, that "stuck green" is a very common problem with WS2812 implementations. I now increased the clock speed a bit and added shorter and longer resets. I also increased slightly the protocol timings for the PIO code - at least, I think it does that. ;D

All of these variants work fine with my ZERO here at least.

LED_timing_trials.zip

[Quas7]

I got bored today and pulled out my scope and tested the code changes I did so far looking at the DI pin of the LED. It is MUCH different than what I expected...

There is no "reset timing" at all... What I understood as the reset-timing was only a delay for getting the bitstream pushed out. Increasing this delay to 300us might have led to some collisions in the timing that resulted in "green" for you and for some reason, it made the LED work for you as well.

I decreased the frequency from 800k to 600kHz and increased the send-time from 50us to 70us and also introduced 10us delay between pin-setup and the bitstream being send out. 231008_firmware2.73_600kCLK_70us-send_10us_pre-sleep.uf2.zip

[Quas7]

Looking again at the schematics of the TINY vs. the ZERO there is one more difference:

ZERO

TINY

Therefore, please find the R5 10kOhm resistor between LED-DI and 3.3V and remove it as a test, if no firmware above solves the issue. And also please check, if it is really 10kOhm and not a lower value.

[lucasromeiro]

Looking again at the schematics of the TINY vs. the ZERO there is one more difference:

ZERO

TINY

Therefore, please find the R5 10kOhm resistor between LED-DI and 3.3V and remove it as a test, if no firmware above solves the issue. And also please check, if it is really 10kOhm and not a lower value.

@Quas7

I just installed all the firmware and none of them worked! But your excellent observation regarding the 10k resistor was incredible! After removing it, ALL firmwares worked very similarly to the original, solving the problem perfectly!!!

Thank you so much for all the support!!

[Quas7]

Glad it worked out.

@Ansem-SoD might be worth a note in your guide, that the pull-up resistor on RP2040-zero is messing with the LED.

[Warlock107]

Hi, first at all sorry for my poor english and thanks for all your work, i have the same problem with a clone RP2040 and i drop 2.73 nothing happend, 2.74 same results, try older version of firmware, nothing happend, no flash when connect to pc anyway... I use this firmware https://github.com/Ansem-SoD/Picofly/files/12830790/231006_firmware_2.73_400kCLK_300us_Reset.uf2.zip and now have blue light when i connect to pc and when i flash with that firmware, can flash it, but nothing with the other from the repository. This firmware its only for test lights or work with N Switch? sorry im noob

[Quas7]

first of all: what clone do you have? RP2040-tiny?

[Warlock107]

idk wich model is, is this one, maybe the name its A3 CORE? its for v1 and v2 in store description. I add a picture, thanks!

[Quas7]

I have no chance to help here. There is no schematic and no layout available for this clone. Note: on some of these modchip modules the resistors are 470 Ohm instead of 47 Ohm and even RST (B) has resistors in series that should be 0 Ohm. I fried one eMMC (not init anymore) in an OLED because of this resistor mess and needed to exchange the eMMC chip. If you install this modchip and get sometimes a "purple screen" during boot-up you might have the same issue and I recommend backing up the eMMC boot1,boot0,full raw, keys etc and installing a proper modchip asap ;)

Best chance is to check on Youtube for someone that used this version.

[Warlock107]

I have no chance to help here. There is no schematic and no layout available for this clone. Note: on some of these modchip modules the resistors are 470 Ohm instead of 47 Ohm and even RST (B) has resistors in series that should be 0 Ohm. I fried one eMMC (not init anymore) in an OLED because of this resistor mess and needed to exchange the eMMC chip. If you install this modchip and get sometimes a "purple screen" during boot-up you might have the same issue and I recommend backing up the eMMC boot1,boot0,full raw, keys etc and installing a proper modchip asap ;)

Best chance is to check on Youtube for someone that used this version.

Thanks flr the tip, i try that firmware and now i have light and can flash it, with the normal firmware i drag to the partition of 128mb and nothing happend, with that modifier firmware, when i copy to the partition just flash one time and disconnect, and works perfect... Just in case someone have this same chip and problem!

[AceCuba]

Hey @Quas7 thanks for every second yous pend on this . Can ypu help i got a fake tiny so the oficial rehus fw the led dont work . What should i do remove r5 resistor and use your cfw ? . And what cfw You recomend

[Quas7]

Just remove the resistor and use the original firmware of rheius (search rheius/usk)