LED Issue with generic RP2040 USB Device

[juliadin]

I have a cheap USB Stick alike RP2040 device with 4MB Flash, used the raspberry pi eddsa image on it.

Using micropython on the same device, I can successfully blink the led on Pin 22 (and one I pinched to the board on Pin 29).

No matter how I provision the device, I can't get the LED to work or to put it differently: to do ANYTHING. The onboard LED just remains 'slightly on', exactly like after erasing the device.

I checked, and from what I gathered the rpi pico image should use the led_pico led_driver which seems also just set the given pin to OUT and control it.

I tried Pin 22, and 29 via the web based pico commissioner (what successfully commissioned the device) without avail...
The values show up correctly when querying via pico-hsm-tool.py from git.
I also tried to update the led_gpio via phy led_gpio and iterated over 0 to 40 without success.

Am I doing something wrong? Or is there somewhing weird about my device?

I got the same issue with the FIDO and OpenPGP firmware on this and an identical device.

[juliadin]

phy value after setting pin 22 and restarting the key:

Current value: b'00105004070416050f060006'

[juliadin]

phy value after setting pin 29 and restarting the key:

Current value: b'0010500407041d050f060006'

[polhenarejos]

Does this example work to you?

https://github.com/raspberrypi/pico-examples/tree/master/blink

Which firmware do you use? Are you sure it is the correct one for your board?

[juliadin]

Regarding the example: it works when I change PICO_DEFAULT_LED_PIN to 22 in the pico board and build it.

I use the 'pico' firmware official 5.0 build from the website - it seemed to match the board the most. I am in fact not sure that it is the right one but since I couldn't even find a board with GPIO 22 as the default LED pin I don't think there is a profile for that board yet.

It is a RP2040 with a Winbond W25Q32JV 32Mbit flash ... so it seemed a fair guess :/. I am also not really far in understanding the intricacies of pico-hsm on different boards.

In some other issue you mentioned that the difference in target boards is - apart from the led - mainly the flash size. Is there more to consider?

[juliadin]

the LED works when I patch the pico.h to define PICO_DEFAULT_LED_PIN 22

what I don't understand is ... shouldn't the commissioner override this?

[polhenarejos]

Depending on the firmware you choose, it will use one driver or another. Do you have the model of your LED?

[juliadin]

the LED is a standard green LED (no integrated logic) attached to pin 22. As I said, when I use pico.h to build the pico-hsm firmware and change PICO_DEFAULT_LED_PIN to 22 it works with pico-hsm as well... It uses the led_pico driver so it just turns the pin on and off:

build $: cmake ../ -DVIDPID=NitroHSM -DPICO_BOARD=pico -DPICO_SDK_PATH=../pico-sdk/
PICO_SDK_PATH is /home/julia/src/pico-hsm/pico-sdk
Target board (PICO_BOARD) is 'pico'.
Using board configuration from /home/julia/src/pico-hsm/pico-sdk/src/boards/include/boards/pico.h
Pico Platform (PICO_PLATFORM) is 'rp2040'.
Build type is Release
TinyUSB available at /home/julia/src/pico-hsm/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
BTstack available at /home/julia/src/pico-hsm/pico-sdk/lib/btstack
cyw43-driver available at /home/julia/src/pico-hsm/pico-sdk/lib/cyw43-driver
lwIP available at /home/julia/src/pico-hsm/pico-sdk/lib/lwip
mbedtls available at /home/julia/src/pico-hsm/pico-sdk/lib/mbedtls
-- VIDPID:			 'NitroHSM'
-- Delayed boot:		 disabled
-- USB CCID Interface:		 enabled
-- USB WebCCID Interface:	 enabled
-- USB VID/PID:			 0x20A0:0x4230
-- LED driver:			 led_pico
-- Found version:		 5.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/julia/src/pico-hsm/build_pico

Changing the LED pin via commissioning or the pico-hsm-tool.py doesn't seem to have any effect in that case as well. Should it?

[polhenarejos]

You are right. There's a bug in the led_driver, as it takes the default one omitting the override. I'll push a fix.

[juliadin]

Thanks! - no further questions here then. If you don't want to track your fix in this issue, feel free to close it.

[polhenarejos]

A fix is available at 07d9e22 in the development branch.
You can build yourself or wait for the nightly development build.