The Raspberry PI PICO 2, now has extra RISC-V cores

[PCB.Wiz]

As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.

My reading has the inductor used on the 1v1 core Vdd, not the analog supply.

30mV is close to 1% of 1v1, so it would raise a flag in the lab.
They are vague on exactly where that 1% bump occurs, we have just 'at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point'

How many vendors offer 3.3uH inductors, shielded, in that package size ?

[iMo]

In order to characterize the ADC you have to get rid of both switchers there (the 3.3V and the 1.1V).
Do replace them simply with linear regulators.
Would be great if somebody comes with a new pcb without any switchers, of course..
The ripples produced by the LC based switchers are pretty hard to filter, as they are rather high energetic pulses.
The setup as it is today is good for less demanding educational purposes, for applications with sensitive analog circuitry or with timing sensitive apps it is simply a nogo.

[MK14]

As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.

My reading has the inductor used on the 1v1 core Vdd, not the analog supply.

30mV is close to 1% of 1v1, so it would raise a flag in the lab.
They are vague on exactly where that 1% bump occurs, we have just 'at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point'

How many vendors offer 3.3uH inductors, shielded, in that package size ?

I agree with you.

It seems I was mistaken.

Instead of my googling, finding relevant RP2350/PICO2 websites, (missed/unnoticed by me) it had found a much older website, (such as one) about the previous PICO, on an Adafruit board, whose SMPS, needed or could be put into PWM mode, under certain conditions.

NOT RELEVANT HERE.

N.B. Please IGNORE the following link.  It is only for people curious as to how I messed up, and was not necessarily the webpage, I used when making previous posts.
https://adafruit-playground.com/u/blakebr/pages/wifi-power-management-for-the-raspberry-pi-pico-w

My mistake!

EDIT:
I've tried to correct the post. here (which seems to have a better link of the wrong information, as well):
https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/msg5605771/#msg5605771

[MK14]

For anyone who is interested, the PICO 2 (original), is now in stock.

Raspberry Pi Pico 2
by Raspberry Pi

For £4 + (for the UK) VAT = £4.80 + Shipping

at Pimoroni (I'm not connected with them, but I do sometimes check their website, fairly often).

Here:
https://shop.pimoroni.com/products/raspberry-pi-pico-2?variant=42096955424851

[iMo]

FYI

[westfw]

[compilers matter]

Yeah, RISC-V seems like a bit of a tool-chain nightmare, with all the different "extensions" that are defined (or vendor-defined.)
I assume that a full-featured gcc will have all of them "usable", assuming that you specify all the right options in the command line, which may take some figuring out.  (Shades of Motorola 68K, especially after adding CPU32 and CPU32+ and Coldfire, with slightly different instruction sets.)

Then there is the "which floating point library did you get?" question.  The C (bloated and slow) libgcc float code (as on vanilla CM0)?  An optimized compiler library provided with gcc (as with CM3 (and I assume CM33))?  A modified something designed to use the improved floating point in the rp2040 ROM, or the "DP accelerator coprocessor" in the rp2350?
(For instance, the Philhower core for Arduino carefully duplicates the SDK-style (horribly obscure) build that uses the ROM floating point in rp2040.  The Arduino core doesn't.  They can perform quite differently!) ( https://github.com/arduino/ArduinoCore-mbed/issues/614 )

[brucehoult]

[compilers matter]

Yeah, RISC-V seems like a bit of a tool-chain nightmare, with all the different "extensions" that are defined (or vendor-defined.)

I don't see why it's a "nightmare".

Generic code runs correctly everywhere.

If you know what chip you're using (as embedded people always do) then you look up the CPU's exact ISA and add that to your CFLAGS and be happy.

It's no harder than figuring out whether you have a Cortex-M0 or M3 or M4f or M33 or A53 in your Arm board. The RISC-V ISA strings can get a bit longer, but it's just a matter of copying it verbatim from your board/SoC documentation to your build commands.

I would assume Gary could have done that with his Windows VSCode setup rather than going to Linux. (Not that going to Linux is a bad idea)

I assume that a full-featured gcc will have all of them "usable", assuming that you specify all the right options in the command line, which may take some figuring out.  (Shades of Motorola 68K, especially after adding CPU32 and CPU32+ and Coldfire, with slightly different instruction sets.)

Of course. A standard RISC-V gcc install from a package manager such as Debian's "apt" can compile your own code with any set of extensions you want, including custom vendor extensions such as those from THead that have been upstreamed. There are also a number of versions of the libraries compiled with various common combinations of extensions, though of course it is impossible to cover all possibilities, so you might end up with library code using slightly more generic code than your CPU is capable of.

It appears that what made the difference in Gary's case is soft FP routines using the "B" extension, off the top of my head I imagine mostly clz for normalising results. This is a baseline extension going forward for pretty much every CPU core released after late 2021, except the very lowest end ones.

[oPossum]

A look at the silicon inside...



https://electronupdate.blogspot.com/2024/08/pi-pico-2-extreme-teardown.html

[langwadt]

https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede

[SiliconWizard]

Ouch.

[iMo]

That happens when you start to play with off the shelf silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..) 

[coppice]

https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede

An MCU with a bug list, most of which will probably be worked around rather than fixed? I'm shocked, shocked I tell you. 

[RAPo]

But be sure to pick the right combo:

Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

[macaba]

Following that compiler video, I investigated a little by running the same benchmark. You do not need to install the toolchain manually, it is available with a small edit of the CMakeLists.txt when using the VS Code extension.

Code: [Select]

whetstone_rp2350.c [13_2_Rel1] Debug (73,216 bytes) - 50.0 MWIPS (10000 loops)
whetstone_rp2350.c [13_2_Rel1] Release (68,608 bytes) - 333.3 MWIPS (10000 loops)
whetstone_rp2350.c [RISCV_COREV_MAY_24] Debug (131,584 bytes) - 1.9 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_COREV_MAY_24] Release (129,024 bytes) - 5.9 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_13_3] Debug (110,592 bytes) - 8.3 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_13_3] Release (105,472 bytes) - 25.0 MWIPS (1000 loops)

In CMakeLists.txt, use one of these to switch between a recent ARM toolchain and the two RISC-V toolchains, when using the VS Code extension. You'll need to close VS Code, delete the build folder, make the change, and reopen VS Code.

Code: [Select]

set(toolchainVersion RISCV_COREV_MAY_24)
set(toolchainVersion RISCV_13_3)
set(toolchainVersion 13_2_Rel1)

Edit: just in case, here is how you switch from Debug to Release build using the terminal within VS Code:

Code: [Select]

cmake build -DCMAKE_BUILD_TYPE=Release


[RAPo]

My pico2 will arrive next week, will try out your suggestions.

[radiolistener]

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want.  E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why.  Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

[MK14]

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

If it was running a proper (full) operating system and directly connected to the internet in a significant way, like a full sized Raspberry Pi running Linux, could be.  Then I'd agree with you.

But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code.  So, should be relatively immune from such attacks.

But, on the internet, there could be downloadable image files for the Pico2/RP2350, with harmful (I don't know if special button/signals are needed, in order to change the OTP, or if anything, at anytime, can mess with the OTP) stuff, designed to 'destroy' your device.

I don't think it is a serious problem.

Perhaps they could have given it some kind of method, for resetting it back into factory default settings mode.

Some other MCUs (IIRC), are also susceptible, because their boot loader code, can be erased/disabled, forcing more dramatic methods of reprogramming it, such as having to use a JTAG device, rather than the usual USB programming (boot) method.  I think (IIRC) some are basically bricked if the boot code is erased/disabled, either permanently or unless you have access to (a possibly VERY expensive, but sometimes there are much cheaper clones available), proprietary factory supplied programmer device.

[radiolistener]

But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code.  So, should be relatively immune from such attacks.

even MCU disconnected from the world can write it due to some mistake in the code or failure.

[MK14]

But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code.  So, should be relatively immune from such attacks.

even MCU disconnected from the world can write it due to some mistake in the code or failure.

You're right, but on the other hand.  Don't forget that this MCU, and many/most other MCUs, can (due to faulty code or failure), over-write their flash based firmware/software, which for something out in the field (e.g. a product released to customers), would essentially destroy the device.

But in practice, with decently written/tested software, and well designed hardware, there shouldn't really be such a problem, in general.

[ataradov]

There are a lot of other MCUs with OTP bits and memories. The programming procedure is pretty complicated, it is hard to invoke it by error. The only somewhat realistic scenario is when your code already had the function, but it was not called yet and it gets called by accident due to incorrect jump. But this is really far fetched.

Ability to persistently lock up the device and prevent any further access even after an erase is a new feature that is being introduced in most new devices, since customers demand that..

[MK14]

Ability to persistently lock up the device and prevent any further access even after an erase is a new feature that is being introduced in most new devices, since customers demand that..

Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

[tszaboo]

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want.  E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why.  Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

Do you let others run code on your microcontroller?

[coppice]

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want.  E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why.  Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

OTP bits to enable or disable various kinds of functionality are widespread in modern MCUs. If someone has managed to hijack your device to the point where they can load and run code that will affect one of these selections you have bigger problems than them tampering with the bits.

[ataradov]

[Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

Not really, I have not seen anyone want to actually destroy the MCU. In most cases there like this there is a tamper detect mechanism and erase of the keys or other data in SRAM. The unit is still alive, but does not work without new provisioning.

The lock is not destructive, it is just really permanent. Once set, you can't erase it. And sometimes you also have persistent boot section, so not even code running on the MCU can ever erase it.

The reason for persistent lock is to make firmware modification impossible without swapping the MCU. This increases the barrier for hacks. If you have some gadget with an older MCU, an independent firmware may be developed and a simple PiPico will let people without any experience change the firmware and unlock the device. But if unlocking requires CPU swap, there is no way ordinary people will be able to do that.

[MK14]

[Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

Not really, I have not seen anyone want to actually destroy the MCU. In most cases there like this there is a tamper detect mechanism and erase of the keys or other data in SRAM. The unit is still alive, but does not work without new provisioning.

The lock is not destructive, it is just really permanent. Once set, you can't erase it. And sometimes you also have persistent boot section, so not even code running on the MCU can ever erase it.

The reason for persistent lock is to make firmware modification impossible without swapping the MCU. This increases the barrier for hacks. If you have some gadget with an older MCU, an independent firmware may be developed and a simple PiPico will let people without any experience change the firmware and unlock the device. But if unlocking requires CPU swap, there is no way ordinary people will be able to do that.

Thanks, that makes a lot of sense.

E.g. Unfortunately, a lot of CCTV security cameras these days, use the business model that the cameras are amazingly cheap and feature packed.  But they then rely on pressuring or forcing the users, to buy subscriptions either for more features or even just to carry on using it, depending on the make and model.

So, if independent firmware was created, a user could hack it, get all the features and not pay any subscriptions.

But, as you just said, if the user had to physically swap the actual MCU, involving fiddly unscrewing to open the device and difficult surface mount soldering, ideally needing specialist equipment, most people, don't have access to, or the know how/experience to use.  Is likely to stop >=99% of users, replacing the firmware, that way.