# Raspberry Pi RP2350
**URL:** https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062
**Category:** General
**Tags:** embedded
**Created:** [August 8, 2024, 5:43pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062 "2024-08-08T17:43:51Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 8, 2024, 5:43pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/1 "2024-08-08T17:43:51Z")
Raspberry Pi released some new silicon today, [RP2350](https://www.raspberrypi.com/documentation/microcontrollers/silicon.html#rp2350).
I’m currently busy with my [C compiler](https://forum.ada-lang.io/t/writing-a-c-compiler/1024) work, but I figured I’d write up some of my thoughts.
There are a few options for running Ada on this chip. These options are not mutually exclusive, but as a small community it seems like we should focus our resources on one or two options.
# Peripheral drivers
1. Update [rp2040\_hal](https://github.com/JeremyGrosser/rp2040_hal) to support the new chip, changing the API as little as possible. This means existing drivers are likely to work, but will miss some of the fancy features of the new chip.
2. Write a new rp2350\_hal crate to implement the HAL interfaces on this chip using SVD definitions.
3. Write bindings to the Raspberry Pi C/C++ SDK and statically link it.
# Runtimes
1. Port @simonjwright’s [FreeRTOS-Ada](https://github.com/simonjwright/FreeRTOS-Ada) runtime to RP2350. Could use the RISC-V cores on the new chip and share some code with the ESP32 port. Might integrate better with the Raspberry Pi SDK.
2. Port [bb-runtimes](https://github.com/AdaCore/bb-runtimes) to RP2350. Probably the best option if we want to explore the new security features of the chip.
3. Build examples using @Fabien.C’s [bare\_runtime](https://github.com/Fabien-Chouteau/bare_runtime) that do as little as possible, leaving everything up to the user.
4. Use some other RTOS like Zephyr or RTEMS.
---
### Author:  [@Fabien.C](https://forum.ada-lang.io/u/Fabien.C)
#### Post date: [August 8, 2024, 8:19pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/2 "2024-08-08T20:19:04Z")
I am a bit disappointed by the clock speed, and I’d would love to know why on earth you put both ARM and RISC-V cores on the same chip!?! But overall it looks like an amazing upgrade.
- 2 x Cortex-M33 🥳
- Double the RAM 🥳
- Support for 2 flash or flash + RAM 🥳
- Hardware TMDS Encoder + HSTX for DIV/HDMI output 🥳
- USB White-Labelling is nice (change USB product and device ID even when booting in UF2 mode).
- Bootstrapping a flashless RP2350 from a simple host, such as another
microcontroller. This plus the DVI output makes the RP2350 a nice embedded “GPU”
From what I can see there’s not much change in terms of peripherals. It should be straightforward to add support from the rp2040\_hal.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 8, 2024, 11:43pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/3 "2024-08-08T23:43:27Z")
I’ve seen comments saying it runs reasonably stable up to 300 MHz, seems fast enough for me.
It sounds like the RISC-V cores didn’t cost much die area and it provides a nice way to A/B test code against ARM to see if a more complete transition to RISC-V in the future makes sense. I love that the core itself is open, there’s Verilog on GitHub!
Really happy to see support for atomics, should simplify SMP use cases.
External RAM opens up a lot of possibilities. Somebody’s definitely gonna run Linux on this.
The boot ROM has a lot more functionality, it’s going to take some thinking to figure out how best to transition the startup and linking parts of rp2040\_hal.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 9, 2024, 3:50am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/4 "2024-08-09T03:50:11Z")
Just to put another idea out there: Maybe we could build on top of the Rust [rp-rs](https://github.com/rp-rs) project?
There’s a [blog post](https://thejpster.org.uk/blog/blog-2024-08-08/) about their progress.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 19, 2024, 10:04am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/6 "2024-08-19T10:04:29Z")
I’m unable to report progress on the FreeRTOS-Ada port to ESP32-H2 (GPIOs in general work, but I can’t get GPIO interrupts), so unless the query I raised with Espressif comes up with an answer I’ll probably shelve it in favour of this chip.
Breaking news: ordered! from Pimoroni.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 19, 2024, 10:14am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/7 "2024-08-19T10:14:49Z")
I’ve got a few Pico 2 boards on order, but as far as I can tell, no US distributor has it in stock yet. A few people got preproduction samples and the first 30,000 chips out of the factory went on DEF CON badges. I think I heard Luke Wren say they’ve got another 100k chips shipping in September, ramping up to higher volume from there.
So, it’ll probably be a few months before we can all play with it.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 23, 2024, 8:11pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/8 "2024-08-23T20:11:07Z")
I’ve got my board! (just the one).
You’ll know how unrewarding it is to bring up an RTOS on a new chip if you don’t have a working debugger. RPi’s documentation is a little unhelpful about what you need in OpenOCD’s setup; [this issue](https://github.com/raspberrypi/openocd/issues/104) is where I’ve got to. OK, using a Segger J-Link is maybe a little unusual, but as you can see it works fine for the arm cores.
I also tried an STLINK/V2 and an STM32F4, both of which support SWD, but OpenOCD says they don’t.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 23, 2024, 8:25pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/9 "2024-08-23T20:25:53Z")
Maybe try updating the firmware on your J-Link?
I usually just use a spare Pico board with the [picoprobe](https://github.com/raspberrypi/debugprobe/releases/tag/picoprobe-cmsis-v1.1) firmware.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 24, 2024, 11:06am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/10 "2024-08-24T11:06:14Z")
The J-Link firmware was up-to-date.
I was trying to get away with kit I have to hand; will have to get a Pi Debug Probe (or perhaps a Pico, but that would be less convenient).
ISTR that connecting to the riscv core requires the debug probe to load some code to the 2350?? which might be a bit advanced for the cortex-m oriented probes such as J-Link.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 28, 2024, 7:22pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/11 "2024-08-28T19:22:16Z")
I _think_ that the problem is that the board defaults to arm, so when the debugger tries to talk to a riscv core it ain’t there.
I found a riscv UF2 file; uploaded it to the board; started openocd; **it connected!!**
I guess the immediate fix is to find an OTP setting that forces at least core 0 to riscv. I really dislike one-time programming.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [August 28, 2024, 8:29pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/12 "2024-08-28T20:29:17Z")
It looks like the `reboot` ROM function takes a flag indicating which core architecture should be used. I wonder if there’s a way to have OpenOCD detect if it’s running in ARM mode and load a little bit of code to call that ROM function with the `REBOOT_TO_RISCV` flag.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 29, 2024, 7:26am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/13 "2024-08-29T07:26:02Z")
There’s an OTP flag to do with this. Section 3.9 of the datasheet says
> The default and allowable values of the ARCHSEL register are determined by critical OTP flags:
>
> 1. If CRIT0\_ARM\_DISABLE is set, only RISC-V is allowed.
> 2. Else if CRIT0\_RISCV\_DISABLE is set, only Arm is allowed.
> 3. Else if CRIT1\_SECURE\_BOOT\_ENABLE is set, only Arm is allowed.
> 4. Else if CRIT1\_BOOT\_ARCH is set, both architectures are permitted, and the default is RISC-V.
> 5. If none of the above flags are set, both architectures are permitted, and the default is Arm.
>
> No CRIT1 flags are set by default, so on devices where both architectures are available, the default is Arm. To change the default architecture to RISC-V, set the CRIT1\_BOOT\_ARCH flag to 1.
Looks like CRIT1\_BOOT\_ARCH is the thing, though I can’t quite make sense of the above vs. the description of ARCHSEL in Table 1352.
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [August 29, 2024, 2:56pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/14 "2024-08-29T14:56:53Z")
OK, I got Ada.Real\_Time.Clock and `delay until` working. The trick was to use the correct `-march` setting.
In the Datasheet’s discussion of the `MISA` register, it says that the ideal `-march` string is `rv32ima_zicsr_zifencei_zba_zbb_zbs_zbkb_zca_zcb_zcmp`, but if your toolchain doesn’t support the Zc extensions (GCC 14.1/binutils 2.42 don’t) use `rv32imac_zicsr_zifencei_zba_zbb_zbs_zbkb`. I had been using the settings from my esp32h2 attempt, `rv32imac_zicsr_zifencei`, but with them - no clock interrupts!
Now for some blinkenlights.
---
### Author:  [@DrPi](https://forum.ada-lang.io/u/DrPi)
#### Post date: [August 31, 2024, 11:58am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/15 "2024-08-31T11:58:43Z")
There’s an article about using the RISC-V core of the RP2350 on CNX-Software.
> **[Using RISC-V cores on the Raspberry Pi Pico 2 board and RP2350 MCU - From...](https://www.cnx-software.com/2024/08/31/using-risc-v-cores-on-the-raspberry-pi-pico-2-board-and-rp2350-mcu-from-blinking-an-led-to-building-linux/)**
>
> Raspberry Pi Pico 2 was released last month with a Raspberry Pi RP2350 microcontroller equipped with two Arm Cortex-M33 cores and two 32-bit RISC-V
---
### Author:  [@DrPi](https://forum.ada-lang.io/u/DrPi)
#### Post date: [September 3, 2024, 10:24am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/16 "2024-09-03T10:24:03Z")
Another interesting CNX Software article :
> **[How to recover a "bricked" Raspberry Pi Pico 2 or other RP2350 board - CNX...](https://www.cnx-software.com/2024/09/03/how-to-recover-a-bricked-raspberry-pi-pico-2-or-other-rp2350-board/)**
>
> Recovering a bricked Raspberry Pi Pico 2 or performing a factory reset on a Raspberry Pi RP2350 board couldn't be easier, simply copy...
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [September 11, 2024, 6:48pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/17 "2024-09-11T18:48:30Z")
I started porting [rp2040\_hal](https://github.com/JeremyGrosser/rp2040_hal) to RP2350, but it’s kind of a mess… I made a lot of assumptions in that library that don’t hold for the new chip and requires a rewrite of many of the drivers.
So I started on a [new rp2350 library](https://github.com/JeremyGrosser/rp2350), mostly minimal type definitions for the registers I actually need, and linker/startup scripts. I’ve found the SVD types aren’t generated the way I want most of the time, so I’m just going to do the type definitions by hand. These are declared in `Pure` packages that should be portable to both CPU architectures and independent of any driver implementations. Some of these might be portable to RP2040 too, but I’m not too worried about that right now.
I’m making an effort to do everything with `SPARK_Mode => On` where possible.
I’ve got an LED blinking with both the Cortex-M33 and Hazard3 cores, though I haven’t implemented a timer for Hazard3 yet.
---
### Author:  [@Fabien.C](https://forum.ada-lang.io/u/Fabien.C)
#### Post date: [September 12, 2024, 8:33am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/18 "2024-09-12T08:33:09Z")
> [@JeremyGrosser](#):
>
> I’ve got an LED blinking with both the Cortex-M33 and Hazard3 cores, though I haven’t implemented a timer for Hazard3 yet.
Nice 👍
> [@JeremyGrosser](#):
>
> I made a lot of assumptions in that library that don’t hold for the new chip and requires a rewrite of many of the drivers.
I would love to have more info on this. From my quick read of the documentation I felt like most of the peripherals are backwards compatible if not completely identical.
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [September 12, 2024, 9:08am UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/19 "2024-09-12T09:08:42Z")
The peripherals are mostly similar, though most of them have added fields. For example, `PADS_BANK` has a new `ISO` flag that needs to be cleared to use a GPIO pin. Many registers are now extended to 64 bits to support higher pin count packages. This complicates many `Volatile_Full_Access` registers.
The boot2 and flash code are very different from RP2040. There are alternate versions for the RISC-V core too.
I’m not saying it’s impossible to get rp2040\_hal working on the new chip, but it’s going to be a lot of refactoring and conditional compilation. I pushed my changes to the [rp2350 branch](https://github.com/JeremyGrosser/rp2040_hal/tree/rp2350) if you want to poke at it, but it’s not really in a usable state.
---
### Author:  [@DrPi](https://forum.ada-lang.io/u/DrPi)
#### Post date: [September 19, 2024, 2:45pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/20 "2024-09-19T14:45:09Z")
In case you didn’t know : [The Worsening Raspberry Pi RP2350 E9 Erratum Situation | Hackaday](https://hackaday.com/2024/09/04/the-worsening-raspberry-pi-rp2350-e9-erratum-situation/)
---
### Author:  [@simonjwright](https://forum.ada-lang.io/u/simonjwright)
#### Post date: [September 19, 2024, 5:12pm UTC](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062/21 "2024-09-19T17:12:25Z")
I see I cleared the ISO flag without realising it was different from the 2040.
Are you sure about 64-bit registers? I didn’t spot any, they seem to use 2 32-bit registers (e.g.
```ada
type TIMER0_Peripheral is record
-- Write to bits 63:32 of time always write timelw before timehw
TIMEHW : aliased RP2350.UInt32;
-- Write to bits 31:0 of time writes do not get copied to time until
-- timehw is written
TIMELW : aliased RP2350.UInt32;
-- Read from bits 63:32 of time always read timelr before timehr
...
```
My problem is that within 10 or so key presses (which generate interrupts on any edge) I get an access violation when the ISR completes and attempts to return to the idle task.
I should add that I’m using the Xh3irq extension, which allows up to 512 interrupts (well, I suspect it’s actually 128, because there’s a 4-bit priority value which needs to be fitted into a 512-bit array in the Hazard3 chip’s internals). That makes 4 interrupt-handling mechanisms I’m aware of (including the basic one, which funnels all external interrupts down one channel).
[Next page](https://forum.ada-lang.io/t/raspberry-pi-rp2350/1062.md?page=2)