I've been using RP2040s in custom designs for some time, but I've always just stuck with the same Winbond QSPI flash device as the Pico up to now. I recently built a board with a different QSPI device though, an Infineon FRAM (CY15B104QSN-108SXI), for various reasons. I thought it looked like this device should be compatible, it's fast enough and supports all the commands (except for erase, since FRAM doesn't need to be erased in pages, you can just write whatever, whenever, wherever you want).
I'm having issues bringing the board up though. I don't use USB on the device, instead I just have the SWCLK and SWDIO lines brought out to a header where I use a Picoprobe to program it, same as I've done on all my other RP2040 designs.
First off, I couldn't get openocd to program/verify properly. It seemed like it would try, but then would throw various errors and fail the verification. If I could get openocd working properly then that would work, but not wanting to dig into that I moved on to another approach.
I was able to compile an image with the no_flash option set, and then use openocd to load it into the RP2040 RAM. This worked well, the MCU came up and started running, etc. I was also able to use this live image to access the QSPI FRAM, both read and write using the standard flash_range_program calls. I tested writing to the FRAM, reading it back, power-cycling and reading it back again, and everything appeared to be working correctly.
This board has a hardware UART interface to a computer, so I wrote some command handling and an interface program so that I could write data 256B at a time through the UART, through the RP2040, to the QSPI FRAM. This worked well, I wrote several chunks of data to the FRAM, read it back, all seemed good. I then used this method to write a real firmware image to the QSPI at the root of the device and tried to boot it.
I have a logic analyzer hooked up to the QSPI bus, and when I power up the bus after writing this image I can see it load boot2 at about 1 MHz and then stop. Assuming the QSPI settings used in the default boot2 aren't compatible with the FRAM, I tried switching to the other options. All of them acted the same way except for boot2_generic_03h.
With boot2_generic_03h, I can see it load boot2 on the QSPI at 1 MHz, and then it moves on and appears to start reading my image at 3 MHz. It doesn't load it all sequentially, it starts at 0x0100, then 0x0104, then 0x01F4, then 0x01F8, then 0x026C, etc. Maybe that's normal? Either way, the data it's pulling out of the FRAM at these addresses all match the binary blob I wrote to it. After about 20ms of reading data at 3 MHz (around 3-4 kB), there's a ~70ms pause, then it reads another 3-400 bytes at 3 MHz, then another ~80ms pause, and then it starts reading data from the FRAM again but this time at 30 Hz (not 30 MHz, 30 Hz). All the read commands and responses look normal, but this speed obviously is not usable. I left it for about 30 min in this state and it was just continuously reading the entire time at a whopping 2 B/s.
So, any ideas what might be causing this? The firmware image I'm trying to load just blinks an LED, nothing special, and it doesn't touch the clocks or any peripherals (the LED is not blinking, so it doesn't look like the code is running anyway):Or if anyone has any other ideas to try I'm open to other options, including modifying openocd somehow to flash the FRAM directly using the picoprobe.
Dropping back to the Winbond device is an option (there's a pin-compatible SOIC-8 I can swap in), but I'd really rather stick with the FRAM if I can get it working.
I'm having issues bringing the board up though. I don't use USB on the device, instead I just have the SWCLK and SWDIO lines brought out to a header where I use a Picoprobe to program it, same as I've done on all my other RP2040 designs.
First off, I couldn't get openocd to program/verify properly. It seemed like it would try, but then would throw various errors and fail the verification. If I could get openocd working properly then that would work, but not wanting to dig into that I moved on to another approach.
I was able to compile an image with the no_flash option set, and then use openocd to load it into the RP2040 RAM. This worked well, the MCU came up and started running, etc. I was also able to use this live image to access the QSPI FRAM, both read and write using the standard flash_range_program calls. I tested writing to the FRAM, reading it back, power-cycling and reading it back again, and everything appeared to be working correctly.
This board has a hardware UART interface to a computer, so I wrote some command handling and an interface program so that I could write data 256B at a time through the UART, through the RP2040, to the QSPI FRAM. This worked well, I wrote several chunks of data to the FRAM, read it back, all seemed good. I then used this method to write a real firmware image to the QSPI at the root of the device and tried to boot it.
I have a logic analyzer hooked up to the QSPI bus, and when I power up the bus after writing this image I can see it load boot2 at about 1 MHz and then stop. Assuming the QSPI settings used in the default boot2 aren't compatible with the FRAM, I tried switching to the other options. All of them acted the same way except for boot2_generic_03h.
With boot2_generic_03h, I can see it load boot2 on the QSPI at 1 MHz, and then it moves on and appears to start reading my image at 3 MHz. It doesn't load it all sequentially, it starts at 0x0100, then 0x0104, then 0x01F4, then 0x01F8, then 0x026C, etc. Maybe that's normal? Either way, the data it's pulling out of the FRAM at these addresses all match the binary blob I wrote to it. After about 20ms of reading data at 3 MHz (around 3-4 kB), there's a ~70ms pause, then it reads another 3-400 bytes at 3 MHz, then another ~80ms pause, and then it starts reading data from the FRAM again but this time at 30 Hz (not 30 MHz, 30 Hz). All the read commands and responses look normal, but this speed obviously is not usable. I left it for about 30 min in this state and it was just continuously reading the entire time at a whopping 2 B/s.
So, any ideas what might be causing this? The firmware image I'm trying to load just blinks an LED, nothing special, and it doesn't touch the clocks or any peripherals (the LED is not blinking, so it doesn't look like the code is running anyway):
Code:
int main(){ gpio_init(11); gpio_put(11, 0); gpio_set_dir(11, GPIO_OUT); while (1) { gpio_put(11, 1); sleep_ms(250); gpio_put(11, 0); sleep_ms(250); }}Dropping back to the Winbond device is an option (there's a pin-compatible SOIC-8 I can swap in), but I'd really rather stick with the FRAM if I can get it working.
Statistics: Posted by suicidaleggroll — Fri Jun 21, 2024 11:00 pm — Replies 1 — Views 65