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