PiicoDev RGB Module Firmware

Mark44641 · 20 June 2022 11:59

So I went to use my RGB and it won’t work…

Using the default MicroPython Example, it keeps saying “Couldn’t find a device - check switches and wiring” I hadn’t changed anything from when I last tested it, and using an I2C scanner, I can’t find the address either…

Anyway, I assume it’s either hardware damage, or firmware issue on the AtTiny806. Figured I at least tried reloading it any suggestions??

Cheers

Liam120347 · 20 June 2022 12:30

Hi Mark,

Welcome

Just to confirm were you using the Expansion board or the default I2C pins on the Pico?
If the forum would be able to take a quick look at your circuit that would be amazing!

The firmware should be pretty robust and deliberate effort should be required to alter the firmware, also just confirming, does the power LED turn on?

Mark44641 · 20 June 2022 13:03

Hi Liam, and thanks - didn’t even realise CoreElec had a forum until tonight!

I am using the Expansion board and no the power LED doesn’t turn on. That’s what made me wonder about the firmware - figured its otherwise a simple circuit - going be the schematic anyway

Liam120347 · 21 June 2022 23:25

Hi Mark,

Sorry for the delay!

I haven’t come across any faulty PiicoDev sensors myself, one last quick test, if you have a multimeter, would be to measure the input voltage. (one side of the solder jumper will be GND)

The firmware can be found on the Core Electronics GitHub
And if you’re keen on reprogramming the module the bottom pin on the back is used program the module, Michael explains in the Factory the process for designing the modules.

The support team is fantastic, so if you shoot them an email mentioning this topic and any other troubleshooting steps, they will ensure your projects stay on track!

Trent5487676 · 22 June 2022 05:51

Hi Mark,

I think @Liam120347 is on the money here.

I’ve you haven’t cut the traces to physically disconnect the LED from the power then I’d say troubleshooting the power to the module will be your first step. By default the LED should always come on as soon as the module is connected to the power.

Mark44641 · 22 June 2022 06:26

Thank you guys,

So there is 3.3v at the I2C PU… If had used it last week without fault, just learning to learn MicroPython then went to use with reason and no show - spent way too long diagnosing my code

Ordered a couple of new one anyway

Liam120347 · 22 June 2022 08:28

Hi Mark,

That’s super odd that it just stopped working - I’m not certain why it stopped working all of a sudden, flashing the firmware might fix it but then you’re not on the MicroPython grind

I’m keen to see what you make!

Mark44641 · 28 June 2022 12:57

Grrr… So bought two more modules and of the two another one is acting weird…

Whilst running the default example, the top LED functions perfectly however the bottom two seem to be slightly scrambled and not changing smoothly… I’ll post a video shortly

Liam120347 · 28 June 2022 13:04

Hi Mark,

I’ve got an RGB module on the bench now, if you could please send through a photo of your setup+Code I can do some quick testing

Mark44641 · 28 June 2022 13:12

Hi Liam,

from PiicoDev_RGB import PiicoDev_RGB, wheel
from PiicoDev_Unified import sleep_ms # Cross-platform compatible sleep function

leds = PiicoDev_RGB() # initialise the LED module with conservative default brightness
# leds.setBrightness(127) # 0-255 set the global brightness to half

# pre-define some colours
red = [255,0,0] 
green = [0,255,0]
blue = [0,0,255]
yellow = [255,255,0]
magenta = [255,0,255]
cyan = [0,255,255]
white = [255,255,255]
black = [0,0,0]

# Example 1: Set LEDs to pure Red, Green, Blue for 3 seconds
#leds.setPixel(0, red)
#leds.setPixel(1, green)
#leds.setPixel(2, blue)
#leds.show() # call show() to update the LEDs with new colours
#sleep_ms(3000)
#leds.clear() # clear the LEDs


# Example 2

i = 0 # loop counter
powerLedState = True
 
while True:
    c = wheel(i/360) # pick a colour from the colour wheel
    leds.fill(c) # fill() will automatically show()
    
    if i % 100 == 0: # every 100 loops toggle the power LED
        powerLedState = not powerLedState # toggle state variable
        leds.pwrLED(powerLedState) # update power LED       
    
    i = i+1
    sleep_ms(5)

As for the setup, PiPico plugged into the Adaptor board and a short cable to the RGB Module.

Tried uploading a video, but not sure how yet

Mark44641 · 28 June 2022 13:23

Not ideal, but here’s a video of my module Failing Module

Liam120347 · 28 June 2022 13:48

Hi Mark,

Thanks heaps for sending those through! Sorry to hear you are having trouble BTW
My setup worked straight away - everything looks fine on your end from the photos but unfortunately, the video didn’t play (unlisted YouTube videos are my goto)

I’m not sure what might be causing the issue - I know carpet doesn’t always agree with electronics (ESD).

I’ll mention @Michael to see if he might have any insights

Trent5487676 · 28 June 2022 23:36

Hi Mark,

Thanks for the troubleshooting you’ve done, it seems like the issue might be hardware related in this case.
Can you send us an email with a link back to this forum thread and we can sort out a replacement for the failed RGB modules?

Robert93820 · 29 June 2022 02:45

Hi Liam

You can say that again. Could be several thousand volts of static charge here depending on lots of things. Bad move all round with anything as sensitive as RPi or anything else for that matter. I personally would not trust that device ever again. The bin would be a good place for it.

I do note the LEDs seem to be powered from the host device. Would there be enough current capability for that. I am not familiar with RPi products but I would not attempt that with Arduino.
Cheers Bob

Mark44641 · 29 June 2022 03:28

Thanks Liam,

Yeah normally I’d agree and don’t normal work on the floor - however seeing though they had already failed seemed the best place to work whilst watching a movie

Thanks again for all the suggestions - I’m still sus about the FW but don’t have easy access to a updi programmer.

Thanks also to Trent, great service by CoreElectronics!!

In regards to Roberts suggestion about current draw, pretty sure the LED module would be minimal, and was having the same issue when powered by a battery source. The modules include its own power rail so shouldn’t be an issue

Cheers
Mark

Liam · 29 June 2022 03:37

Hi Bob,

Yeah the 3v3 pin from the Pico is capable of delivering up to 250mA (Source pg8)

Which will be more than enough for the LED’s and a range of other PiicoDev modules!

At full power the WS2812Bv5’s use about 26mA each, well within the 250 (plus full brightness is blinding).

The data-in wont put any stress on the microcontroller onboard so no worries there!

Liam

James · 29 June 2022 03:40

Hi Mark,

If you have a schottky diode, a few-hundred-ohm resistor, and a usb-to-serial converter like a CH340 you can assemble a serialUPDI programmer as described here:

github.com

SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

# SerialUPDI
SerialUPDI is a UPDI upload tool which uses a normal USB serial adapter with the most trivial of modifications directly as a UPDI programmer
It was written in 2020-2021 By Spence Konde and Quentin Bolsee based on the pymcuprog tool from Microchip, which is much, much, slower.

## jtag2updi? Never heard of him
This page was formerly dedicated to discussing jtag2updi. jtag2updi was a program written in some of the most inscrutable C++ it has been my misfortune to work with, and it could be loaded onto a wide variety of AVR microcontrollers, and they could then be used as a UPDI programmer. The code was buggy, and very few people could make sense out of it. It's performance was passable, though, for example, Optiboot performed better at uploads, and both Optiboot and jtag2updi were stuck with baud rates 1/4th to 1/3rd of what the chip could be written at.. In late 2020, the first versions of SerialUPDI were created from pymcuprog, but the performance was very disappointing. In mid 2021, a push was undertaken to make it perform better than jtag2updi. The progress and the short time it took to make it exceeded all expectations. Since the 2021 performance sprint, SerialUPDI - which had write speeds as poor as 600b/s at the time this effort was started, advanced very rapidly. Within just a few days, speeds over 10k were achieved and within weeks it was faster than everything else. 
Since then some further performance enhancements, as well as ways to throttle it's performance to make sure it didn't overflow the part's receive buffer while it was writing

SerialUPDI is not perfect, but it's imperfections are small compared to those of jtag2updi, and less-initiated individuals are better able to improve it as compared jtag2updi - particularly as most of SerialUPDI's foibles are almost entirely due simply to it having not gotten enough attention from people who know how to write python - so things that should retry on failure or print error messages instead print stack traces, because something's throwing an exception and I don't know how to catch it. But the low level core that writes to the chip is largely fine. As of 11/21, we are no longer offering support for jtag2updi. The cores still support it, but it is not recommended. I will fix no bugs. If someone else wants to leap into this dumpster fire, by all means go ahead. I choose not to.. The only way that thing could be salvaged involves essentially rewriting it de novo so it wasn't a posterchild for how incomprehensible C++ can get.

## Brief orientation: What is UPDI
UPDI is the interface used for programming all AVR parts released since 2016 (the "modern AVRs") (and debugging, but that's locked behind a proprietary interface that nobody has bothered to reverse engineer, even though you can snoop on the protocol with just a serial adapter and even though the large scale structure of the protocol is known too - c'mon guys, this is gonna be a walk in the park compared to debugwire). Unlike the old ISP interface, which was very SPI like (in fact, It seemed to be SPI with the reset pin used like SS, and a somewhat odd pattern of communication). This time, we have a somewhat more sophistcated interface that we're connecting to (they call it the  Asynchronous System Interface (ASI)), and the communication method is via what looks suspiciously like they put another copy of the UART in, hardwired to always be in LBME (half-duplex single wire), 2 stop bits, even parity, and autobaud enabled and WFB (wait for break) as soon as it initializes. This talks to the ASI, which initially only lets you reset the chip and read the device ID and SIB (system information block). 

To enable the programming or debug modes, a "key" is sent - there are three in the datasheet (programing mode, chip erase which as usual is how you unlock and erase a locked chip, and program USERROW which can be written even while the chip is locked). There is also a debug key, I don't know what it is, but if I had a working debug setup with microchip studio, it should be trivial to recover by snooping on the communications during debugging. I'd also wager that this is the way they configure what pincount a part is (since most of the AVR dies these days get put into 2-3 adjacent 

Because it's basically a UART, and it looks like they simply copied the UART, only pointed it at the ASI. UARTs have 2 bytes of buffer on receive. Since halting for flash halts the CPU - but not the peripherals like the UPDI physical layer - it will buffer two bytes and lose dataon the third; this results in, at the end of the page being written, the programmer having written more bytes than the target received, causing the programming to fail at that point, because the the part is still treating the next command as data to write, and doesn't respond. 


## Wiring the hardware
Briefly, you connect Rx and Tx with either a 4.7k resistor or a small (signal) Schottky diode (band towards Tx). The RX like becomes the UPDI

This file has been truncated. show original

I’ve used this setup, and it works a treat.

I know this isn’t the main problem but I thought I’d put that out there.

-James

Robert93820 · 29 June 2022 04:15

Hi Mark

I get the feeling that by working on the carpet you might just have made sure that device may never work properly again.

I could be missing something here but in all my many years of experience in building things, installing things and commissioning things I have never ever seen anyone who could concentrate fully on what they are doing and think logically while watching a movie. Indeed some years ago I headed up a team to install a full TV studio. Whilst working these guys insisted on playing loud music (much to everyone’s annoyance). After they returned home I was left to assist the set to work and commissioning this studio and had to spend many hours day and night locating and fixing the many mistakes made by supposedly very experienced installers. This was a Capital City TV station so quite extensive and these fixes were no mean feat. I vowed then this would never happen again and it didn’t.
Maybe the modern mind is better at multi tasking (entertainment plus serious work) but I have yet to see it.
Cheers Bob

Topic		Replies	Views
PiicoDev with the Pico-W Support	15	645	13 September 2022
Pico connection issues with PiicoDev and H-Bridge controllers Micropython	12	226	1 March 2023
RGB Led Module I2C Address Specs Arduino Arduino	4	192	31 October 2022
Using PiicoDev VEML6040 with Kitronik Robotics Board Core Electronics	5	206	19 August 2023
PiicoDev Motion Sensor MPU-6050 - could not communicate Raspberry Pi	4	291	10 October 2021

PiicoDev RGB Module Firmware

Related Topics