17 replies to this topic

[DDH69]

Has anyone managed to set the address on a Pico 2 used as a PWM Worker?  I've setup a number of PWM workers previously but they've all been Pico not Pico 2.

 

Pico = RP2040 version 2, ROM 3 - RP2040-B2

Pico 2 = RP2350 version 2, ROM 2 - RP2350-B1

 

I have a number of Pico and Pico 2 boards on my bench, and I can set the address of a Pico PWM worker with

 

SetPWMWorkerAddr 31 D:

 

When I use a Pico 2 the utility returns "No Picos in Boot Loader mode detected".  The devices certainly are in boot mode, I can see them as a drive (D:) and if I start the config tool I can see them there.  Have tried a number of Pico 2 boards, all same result.  If I swap back to a Pico it works immediately and reliably.

 

Yes I am using the Pico and Pico2 PWMWorker builds as per the board.

 

Is there a way to set the address manually without the SetPWMWorkerAddr tool?

[mjr]

I'll have to take a look at the utility.  I think it does some validation against the self-identification pseudo-file that the device provides when in boot loader mode, to make sure it's a Pico, and I'm guessing the Pico 2 is identifying itself as a different device type from the original Pico.  I don't think there's any intrinsic reason a Pico 2 can't work, but I'll probably have to include its identifier information in the scan.  I'll try to take a look.

[mjr]

I took a quick look, and RP2350 should already be recognized.  Are you using a real PIco 2 or a clone?  What's in the INFO_UF2.TXT file you see in the pseudo-drive when your Pico 2 in boot loader mode?

[DDH69]

Genuine Pico 2.

 

UF2 Bootloader v1.0

Model: Raspberry Pi 2350

Board-ID RP2350

 

I am trying to work through the code of SetPWMWorkerAddr.  Probably obvious to you, but I suspect this is failing to return any drives ...

 

    auto drives = PinscapePico::RP2BootDevice::EnumerateRP2BootDrives();
    if (drives.size() == 0)

[DDH69]

mjr, OK it stumped me for a moment.  In short, the SetPWMWorkerAddr.exe in the release does not match the source.

 

I was examining the source, couldn't see an issue.  Eventually downloaded the source and tested there, all worked.  Compiled a clean EXE version, all good.  Downloaded the latest release again, tried the EXE, failed.

 

So I'm fine, but the release could do with an update to not trip up the next person.

Edited by DDH69, 23 April 2026 - 04:23 AM.

[mjr]

Ah, okay, I must have added the RP2350 recognition since the last release.  (The source in github is always ahead of what's in the release build because I check in work as I go, but I only publish releases at certain points where I think it's reasonably stable.)

[DDH69]

Thanks mjr.

 

Unfortunately the Pico 2 issues are not done yet.  Now that I can set the address I have discovered that I cannot make the Pico 2 run as a PWMWorker.

 

My setup is ...

- Three sets of boards made with 3 x Pico (1 or 2), one main Pinscape Pico for LED, Aceelerometer, Button inputs, and 8 outputs, then two PWM Workers for RGB LED and power outputs.

- All three sets of hardware work with 3 x Pico

- If you add Pico 2 for the PWM worker then you get errors.

- It doesn't matter if you have a Pico or Pico 2 as the Pinscape Pico

 

I'm at a bit of a loss and would appreciate some guidance.  As always, happy to test most things.  I've attached a log with two boots using a Pico (1) as the Pinscape Pico.  The first boot uses Pico (1) as the PWM Workers and works, the second uses Pico 2 and fails.  This is on the same hardware just swapping out the 2 x PWMWorker Pico's

 

I hate to come in without thinking it through so, given the failure is for the WHOAMI my only thoughts are:

1. The setting of the address failed and I can't tell (default 30 is OK, but 31 fails)

2. The Pico 2 has isn't reading the set address due to architectural differences.

3. A timing issue

 

Addendum - After more testing I'm favouring theory 1 or 2 above.  All Pico 2's worker 31 fails, change worker 31 to a Pico (1) all works.  Completely reloading worker 31 makes no difference.

Attached Files

•  OneVsTwo.txt   18.58KB   2 downloads

Edited by DDH69, 25 April 2026 - 01:48 AM.

[DDH69]

mjr, with Pico 2 having double the flash is the SetPWMWorkerAddr setting the address half way through the flash not at the top?  I can see what the SetPWMWorkerAddr program is doing but have no idea how the firmware decides where to get the address from.  If the firmware uses something like sizeof(flash) then it will read the top and the address will not be there ....... OK, this is my latest theory, shoot me down or otherwise 

[mjr]

The address-setting problem theory sounds plausible, but I took a quick look at the code and it's using a fixed flash address, independent of target device type.

 

If you take the Worker Pico 2 with its address set to 0x31 (at least, after attempting to set it to 0x31), and you connect it alone on the I2C bus (without the a second Worker Pico connected), what do you see if you do a bus scan?  That should at least distinguish between a problem setting the address, and the thing not working at all - if you see a device show up at address 0x30, then you're probably right that it's a problem with the address-setter program.  If nothing shows up in the bus scan, and/or the one device at address 0x30 doesn't initialize properly (per the log), then it's something else, like the address-setter is corrupting the main firmware program in flash, or the firmware program is crashing at startup when it reads a non-default address (and apparently only doing that when running on a Pico 2).

[DDH69]

Test result for above with only the device "set" with 31 connected shows as device 30.  So yes, what you say sounds correct.  Perhaps 3 possibilities:

1. device not being set to 31

2. PWMWorker code not reading 31

3. Pico 2 overwrites 0x10000000 + 2*1024+1024 - 4096 when running the uf2

 

Thoughts:

a) Is there a way to read the block 0x10000000 + 2*1024*1024 from a PC?  Could try to read set address after setting and also after running the uf2

b) On the Pico 2 I believe top of RAM would be 0x10000000 + 4*1024*1024 ( -4096)  is it worth trying to move the write and read to this location is its a Pico 2?

 

Edit - Not sure if its relevant but I just noticed, with the "31" device being seen as 30, there is still and error in the log for Worker Pico[0] (the 30 device) being "I2C error requesting register reset (CTRL0_RESET_REGS).  Not sure if this is relevant.  I first read all the red lines as WorkerPico[1]

Edited by DDH69, 25 April 2026 - 11:47 PM.

[mjr]

a) Is there a way to read the block 0x10000000 + 2*1024*1024 from a PC?  Could try to read set address after setting and also after running the uf2

 

You might be able to do that with the "picotool" in the Raspberry Pi Pico SDK.  picotool lets you inspect certain things in the device's configuration, although I'm not sure if it lets you view the flash contents from the command line.  It's kind of a pain to set up, though, because you have to muck around with a third-party device driver setup tool.  The RPi site has setup instructions if you want to look into that.  Unfortunately, it's not something the Pico boot loader does natively, so it's not something that my address-setter program has access to, without also having to go through that annoying device-driver setup step.

 

 

b) On the Pico 2 I believe top of RAM would be 0x10000000 + 4*1024*1024 ( -4096)  is it worth trying to move the write and read to this location is its a Pico 2?

 

The "topness" of it all truly doesn't matter.  It's just a fixed address that the program reads from.  I chose the "top" of a regular Pico's address space because that's safely out of the way of the program image, which always gets installed at the "bottom" of flash.  2MB into the flash array is just as unlikely to conflict with the image on a Pico 2 as it is on a regular Pico, so I think it's better overall to just use that fixed address across the board - that way the address-setter program doesn't have to try to figure out what kind of Pico it's addressing and go through a list of different cases for each one.  Every complication like that is a potential bug.

Edited by mjr, 26 April 2026 - 01:32 AM.

[DDH69]

mjr, would you mind compiling the SetPWMWorkerAddr program and sending to me so that I can rule in / out my compilation of that program.

[DDH69]

OK Mike, I've done more, but still do not have a final solution.  Here is the current situation ....

 

- I do not need a compiled version of SetPWMWorkerAddr.  I have established that my version is setting Pico OK, assuming Pico 2 OK as well but ultimately cannot tell.

- I agree that the address at 2Mb should work for both, butjust in case I moved to 4Mb

- I have made a version of SetPWMWorkerAddr that self determines if its a Pico or Pico 2 connected and sets the address at top of 2Mb or 4Mb

- Based on your great instructions I have managed to compile a uf2! 

- I have made a version that recognises the Pico / Pico 2 and reads from 2Mb or 4Mb top

- None of this has made the Pico 2 read the data

- I made a temporary uf2 that bypassed the signature check and it defaulted to 30

- I have made a version of PWMWorker that defaults to address 31.  This allows me to prove as much as I can that  its definitely a failure to set address.  While this technically makes my setup work, its an ugly solution.

 

Thoughts, suggestions?

[DDH69]

Mike,

 

A  further update.  I now know what the problem is, the question is what is the neatest solution.

 

- The issue is that RP2BootDevice::WriteUF2 function is returning true when it is not successfully writing to a Pico 2

- I have verified this by using picotool to download the memory on a Pico 2 where SetPWMWorkerAddr should be writing to and there is no data after getting a "successful" load

- Have downloaded the memory from a Pico and can see the signature and address

- Then loaded this downloaded block to a Pico 2 via picotool and have the PWMWorker reading the address

- At present I am doing this with a version of PWMWorker that uses 0x10000000 + 4 1024 x 1024 - 4 x 4096 - seems to be the recommended spot in memory as it avoids last block E10 errata documented issue and the wi-fi block, etc

 

Its your project, so your decision, but my current thoughts are that the best path would be:

1) Fix the WriteUF2 function to work with Pico 2 - Sorry but this is beyond me

2) Use the code I have written (or similar) to store the address near 4Mb.

 

Let me know your thoughts.

Edited by DDH69, 27 April 2026 - 05:43 AM.

[mjr]

> I have made a version of PWMWorker that defaults to address 31.  This allows me to prove as much as

> I can that  its definitely a failure to set address.  While this technically makes my setup work, its an ugly solution.

 

That was a great idea to try that.  I agree it's not a viable solution but it really does make it pretty certain it's the address-setter that's the problem.

 

> The issue is that RP2BootDevice::WriteUF2 function is returning true when it is not successfully writing to a Pico 2

> I have verified this by using picotool to download the memory on a Pico 2 where SetPWMWorkerAddr should be

> writing to and there is no data after getting a "successful" load

 

Aha.  There must be something different about the Pico 2 boot loader implementation, then.

 

> At present I am doing this with a version of PWMWorker that uses 0x10000000 + 4 1024 x 1024 - 4 x 4096 -

> seems to be the recommended spot in memory as it avoids last block E10 errata documented issue and the

> wi-fi block, et

 

I wasn't aware of that issue on the Pico 2 - I'll look it up.

 

> Its your project, so your decision, but my current thoughts are that the best path would be:

> 1) Fix the WriteUF2 function to work with Pico 2 - Sorry but this is beyond me

> 2) Use the code I have written (or similar) to store the address near 4Mb.

 

I'll take a look and see what I can come up with.  Thanks for doing all the tests to pinpoint the source of the problem.

[mjr]

I think I've gotten to the bottom if it.  The RP2350-E10 erratum was a red herring, but reading through the details led me to the real problem, which is that Raspberry Pi made a subtle change to the UF2 details for RP2350.  I've made the necessary changes, so it should work now.

 

Here's a test build for you:

 

mjrnet.org/pinscape/downloads/SetPWMWorkerTest-20260428.zip

 

This is more evidence that RP2350 really is a whole new platform with significant differences, so I think Pinscape on RP2350 still has to be considered to be experimental (not fully tested or supported yet).

[DDH69]

That has correctly set the address at the 2Mb address.  All is working as intended, thank you.

 

I didn't realise they were significantly different when I just grabbed 20 x Pico 2 as the easiest availability where I am.  I must say though, now that I have two setups with status LED, IR in, IR out, accelerometer, ADC, 3 x 74HC165, and two worker pico 2's, two I2C  bus, I feel pretty confident that the core stuff is certainly running.  I can also confirm for anyone following that mix and matching Pico and Pico 2 is fine between the master and worker(s).  I am moving Pico / Pico 2 in and out of the same board (I use sockets) and they are directly interchangeable.

[mjr]

That's great!

 

> I didn't realise they were significantly different when I just grabbed 20 x Pico 2 as the

> easiest availability where I am

 

I'm glad it's getting some real testing - that's the main thing that makes me less than confident about it, since I've only tested the really basic stuff with Pico 2 myself.  I think Pico 2 will eventually become Raspberry's main microcontroller offering (until they come up with a Pico 3, anyway), so it'll be good for the project's long-term usefulness if it works reliably on Pico 2.  But it looks like it'll be a while until we're forced to move everything over - it looks like Raspberry Pi has committed to keep the RP2040 in production through at least 2041, so we still have 15 years on these things.