The Pico SDK 2.3.0 introduces significant RAM optimization capabilities for RP2040 and RP2350 microcontrollers, including the ability to reduce XIP cache from 16KB to 8KB to reclaim 8KB of usable SRAM, and standardized PS RAM support with malloc/free heap allocation. Additionally, the SDK now includes a production-ready low power library that simplifies implementing sleep and hibernate modes, addressing the historical challenge of waking processors from dormant states.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
This 'Minor' SDK Update Unlocks Hidden RAM on Your RP2350
Added:So, Raspberry Pi have launched a new Pico SDK version and it's pitched as a minor update.
But, there's actually some really serious new capabilities in here and you need to know about them.
We've got tools to more easily squeeze every byte of RAM out of our RP2040 and RP2350 and better PS RAM support for the RP2350.
We've also got low power support, finally. And that's hitting the SDK proper, so we can do sleep and hibernate for your boards.
Plus, the continued board ecosystem explosion. Every new version of the SDK generally has loads of new Pico boards and this is no exception.
If you're using Visual Studio Code and the Pico um extension, then you should be able to just upgrade and it should actually just prompt you to download the new SD card. So, that should be fairly straightforward and simple.
If like me, you actually run an external tool chain to actually do all of your compilation, then you're going to need to pull down the new SDK and it's available on GitHub over here. Check out the version 2.3.0 and uh away you go. And that's what I'm going to be doing.
So, RAM embedded systems can sometimes be a bit of constraint and we have to squeeze everything to make them fit.
Well, with this update, we've got two options to actually make that a lot easier for us.
First of all, there's this thing called XIP cache, which they're allowing us to actually use a bit. XIP cache is where the code that's lying in your flash that you're going to actually execute is copied to before the processor actually runs it. And the reason it's copied over from the uh into uh XIP cache is so that the processor doesn't have to hang around and wait for the access of that flash. Flash is at least 16 times slower than main RAM.
So, really having it in main RAM to actually execute means the processor isn't hanging around.
Now, there's 16 KB of that used in this XIP cache area. Now, with this new extension, our new capability of the SDK, we can now actually reduce that and use 8 KB of it as additional SRAM. Now, that means that we can actually place into our C make file that we're going to use XIP cache as RAM, and we can define that. And then in the variables in our code, we can actually mark them up and say that we actually want them to be in XIP RAM. And that means that actually we start moving some of our code from main RAM into this area and gain that extra 8 KB of RAM if you really need it.
The other RAM enhancement in this new version of the SDK is for PS RAM. Now, PS RAM's been around since we had the OPY 2350 launch. We've always been able to actually add some additional RAM to the QSPI bus, the same bus that is driving the flash RAM, and and add in this additional RAM. Now, you've seen me do it. I've done it on some of my examples so that I can drive some additional big screens and touch screens and have enough room to actually plan build systems in those.
But, with this update, we actually get to solve a number of problems when using PS RAM. The first thing is there is no standard way of telling the SDK or indeed your application how much PS RAM you've got on this board.
Well, now there is and there's a standard definition for that been added.
Also, the chip select pin can be different for different boards. You we need to actually select to actually read from this PS RAM physical chip. And yeah.
Now we have a standard definition for what that's chip select pin is going to be.
And finally, the other thing that is really difficult working with PS RAM is is an additional different memory space.
And we want to be able to allocate memory in there for various variables and stuff and I want to do that in a way where I'm sort of almost using it as a new heap with malloc and free commands.
Well, the SDK 230 has got malloc and free commands that allocate specially from this area. So, that's really, really cool and gives us everything we want. In fact, those malloc and free commands are actually even cleverer because if they run out of room in PS RAM, they're trying to allocate from main RAM.
Now, admittedly, I think PS RAM will nearly always be bigger than your main RAM. So, whether they actually ever do drop back to main RAM or not is an interesting point. But anyway, I wanted heap access and I've got it.
So, before we dive deep into what the new Pico SDK has, a quick shout-out to today's sponsor, wolfSSL.
If you're building anything on the RP2040 or RP2350, whether it's a connected robot, a sensor node, or a full IoT device, security and reliability matter more than ever.
wolfSSL delivers a lightweight embedded friendly TLS and crypto stack that actually fits the constraints of microcontrollers instead of fighting them.
Their wolfSSL library gives you fast modern cryptography that's optimized for exactly the kind of hardware we use on the Pico projects. So, if you're encrypting data, securing firmware updates, or protecting communication between nodes, wolfSSL keeps things safe without burning cycles of RAM.
And if your project needs networking, wolfSSL also offers wolfIP, a compact embedded IP stack designed for devices that can't afford the overheads of a full Linux-style network layer. It's perfect for microcontroller-driven robots, automation systems, and anything running in this Pico ecosystem.
So, whether you're experimenting with the new SDK features or building something that's going to ship, wolfSSL gives you the tools to secure your projects end-to-end. Check out wolfSSL using the link below, and thanks to them for supporting the channel.
Sleep. Low power modes for our Pico and Pico 2. There are lots of opportunities in this, and in fact, on the RP2040, I actually have explored this going into deep sleep mode and going into a hibernate mode. And I showed how they worked, and I was building all of that in order to support the weather station project I worked on probably about 3 years ago now.
Um generally though, I've found that working with sleep and and dormant modes was kind of on the too hard list.
[snorts] Not that it's hard to put the processor to sleep, but it is hard to wake it up and get it into a fully awake state. And that was really the big challenge on doing that. So, so now we've got a new library called Pico low power, and that's giving you a new code to be able to actually drop the processor into a sleep mode or into a full dormant mode, get it to wake from a particular GPIO line, or from the internal clock, and all good. And it's production code now. Production SDK, so we shouldn't have the same challenges we had previously. And we've also now got full support for the RP2040 and RP2350, which should make this a lot easier to work with. So, I'm going to be trying this out actually on a future project I think, cuz this is an area I want to get back to.
Now, with every new SDK release, there are always new boards supported in the SDK.
We always put a board definition in our C make file, and those board definitions, and that's where we get new ones. You can write your own custom ones, and I've done that on the channel as well.
So, in this version of the SDK, we're getting a 11 new boards. And the ones I picked out that I thought were interesting is things like the debug probe is now a dedicated board type.
Does this mean that we should be actually using debug probes for our own projects?
That's an interesting idea.
I wonder what you could do with building it on a debug probe.
Give me if you've got some thoughts, put them in the comments.
Also, we've got the Raspberry Pi Pi 500 RP2040, so where they've actually put an RP2040 into that Pi 500 keyboard.
That's now supported as a dedicated board type.
And indeed, the Waveshare RP2350 Pi Zero, which I also reviewed on the channel, and we did some direct video output over DVI directly to a screen using that board. That's all supported now, too. So, that's great. We've got those boards. And that last one uses PS RAM, and of course, now we've got that nicely standardized, so there's a standard definition for that in the board file, rather than me having to um hack it, which I did in my example.
And those PS RAM definition updates have been done to a number of boards as well in the backlog. So, actually we're getting more standardization with how these boards are all working with PS RAM, which is promising.
There also have been a number of library updates, of course, within this uh version of the SDK.
And those include things like uh the USB reset capability.
Um that's now been distilled out from uh the standard IO library into its own little library, so that we actually can more easily use it with different USB definitions if we choose to do so.
The BT stack, the Bluetooth stack, that's been upgraded to version 1.8.2.
That's great. I'm I haven't played much with Bluetooth yet um on the channel or in reality. I've got a mind for a Bluetooth project coming up though. So, um I this updates uh good moment for that for me.
And uh mbed TLS. So, if you're using TLS and you're communicating over sockets, then that new version of the um mbed TLS closes some of the security issues, which is also good. And basically it's just a security update.
There are a whole load of other bug fixes and small tweaks to libraries, making libraries better and generally moving them forward as well. But, these were the big three that I picked out.
So, the Pico SDK 2.3.0 gives us a bunch of new stuff. Um it's pitched as a minor release, but I think that really undersells it. I'm mostly excited here by the PS RAM support. Honestly, I've had to write my own PS RAM heap functions before now um to get some of my examples to work on some of my projects to work. And this makes a huge difference now having that as part of a library.
I will confess that I've almost given up on putting Pico's into sleep or deep sleep mode completely. It's just too hard. But we've got a new library now that's actually productionalized that and that reinvigorates me to go look at that area.
So, how about you? What do you want to try next with this new Pico SDK version?
Please let me know in the comments. I'd really be interested to hear. And if you've got ideas you'd like me to explore, then let me know, too.
And remember to like and subscribe. And why not join the channel and get access to all my videos as soon as I upload them rather than having to wait for the schedule. See you on the next video.
Related Videos

TOP 15 Data compression Interview Questions and Answers 2019 Part-2 | Data compression | Wisdom jobs
wisdomjobs
281 views•2019-06-28

CTS 158: 802.11w Management Frame Protection
ClearToSend
4K views•2019-02-04

NDSS 2019 Send Hardest Problems My Way: Probabilistic Path Prioritization for Hybrid Fuzzing
NDSSSymposium
496 views•2019-04-02

How realistic is Cities: Skylines?
CityBeautiful
159K views•2019-02-14

GUIs & TUIs: Choosing a User Interface for Your Python Project | Real Python Podcast
realpython
2K views•2025-04-04

The OSI Model - Explained by Example
hnasr
225K views•2019-05-12

Cloud Computing - Introduction
elithecomputerguy
98K views•2019-10-07

From Traveler's Dilemma to Dynamic Routing | Demystifying Networking
IITBombayJuly
5K views•2019-08-04
Trending

WOW! Judge TURNS THE TABLES on Trump in His OWN $10B LAWSUIT!!!
MeidasTouch
197K views•2026-07-23

Playstation NO DISC/NO BUY Fight Is Over...
DavidJaffeGames
4K views•2026-07-23

Steam and Xbox Just Dropped The Hammer On PlayStation
OhNoItsAlexx
9K views•2026-07-23

Americans Confused in Australia for 17 Minutes Straight
IWrocker
17K views•2026-07-23