Comments (8)
Hi @Mikefly123. I spent an evening on this and made decent progress. Posting my crude hotfixes below in case it helps you.
Bottom line: I have the rp2040 booting pico-sdr examples as well as full-fledged micropython from an MRAM device (MR20H40) and utilizing the unused MRAM as a filesystem. Everything works across power cycles and the bootloader properly recognizes there is off chip flash at boot.
- The only detail I could not resolve in my evening of hacking was accessing/utilizing more than 512K of the (4MB) MRAM chip, but I would guess this is a vendor/part-specific issue.
- In my case, any writes beyond XIP_BASE + 512k loops back to the start of the memory and begins overwriting firmware.
- My first guess would be this specific chip PORs with some specific write protection settings that need to be configured as part of boot2_generic_03h.S.
Key changes made (let me know if you need more detail and I will circle back when I have time):
- Specify
#define PICO_BOOT_STAGE2_CHOOSE_GENERIC_03H 1
in your boards definition file. - Clock the QSPI bus very slow while you are first ironing kinks out. I used
#define PICO_FLASH_SPI_CLKDIV 8
(also defined in boards definition file). - In my case, set the flash size to
#define PICO_FLASH_SIZE_BYTES (500 * 1024)
in order to not overwrite itself on subsequent boots - Don't forget to add a pull-up (10k ish) to the chip select line if you chip needs it (likely does).
- Not wanting to deal with unknown bits after an erase flash command (since these MRAM chips don't have an erase cmd), I threw a crude temporary fix into https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_flash/flash.c that writes all
0xFF
to the range of memory as part of theflash_range_erase
function call. Obviously you would want a better solution long term, and at the very least wrap it in some precompiler checks for MRAM builds. What I have for now looks something like this:
void __no_inline_not_in_flash_func(flash_range_erase)(uint32_t flash_offs, size_t count) {
...
uint8_t eraseBuff[count];
for (int i = 0; i < count; ++i) {
eraseBuff[i] = 0xff;
}
// No flash accesses after this point
__compiler_memory_barrier();
connect_internal_flash();
flash_exit_xip();
flash_range_erase(flash_offs, count, FLASH_BLOCK_SIZE, FLASH_BLOCK_ERASE_CMD);
flash_range_program(flash_offs, eraseBuff, count);
...
What I haven't done (but someone should!) is take a proper approach towards MRAM implementation to take full advantage of the speed and endurance characteristics.
Good luck and let us know how it goes!
from pico-sdk.
Hey @maholli! After reading your hotfixes and tinkering around, we managed to boot and successfully build and upload the firmware into our RP2040, which is currently booting from the same MRAM model!
We really appreciate the insight that you shared with us. If you don't mind me asking, could you please explain a little more about the erase flash command that you created and give us a few pointers on how to create a more coherent erase function? I'm especially curious about what you meant by "wrapping it in the precompiler checks for MRAM builds."
from pico-sdk.
We are also very interested in whether or not MRAM support will officially come in someday. Specifically we're looking at the ASxxxx204 family of chips but the functionalities should be roughly equivalent.
We've run into some of the same issues as @maholli and are also rifling around to see if there is a work around. If we can get the RP2040 booting from MRAM we have the funding to book radiation testing time for both high energy proton and heavy ion to shake down the performance of a combined RP2040 / MRAM system.
from pico-sdk.
To add a little more context on what we managed to get working:
- We managed to get one of our RP2040 equipped EPS boards running our PicoSDK Firmware with an Everspin MR25H40.
- We also got one of our RP2040 equipped flight controller boards running the PicoSDK Firmware with an Avalanche AS3016204-0108X0PSAY.
a. As a fun convenience feature the Avalanche parts has a 4x the memory of the Everspin part at 16Mb, supports QSPI, and is the same footprint as SOIC-8 footprint as COTS flash (so we don't need the chimera footprint on PyCubed!)
As an extra tidbit:
- When using PicoTools we see 512K (Kilobytes) which is the same as 4MB (MegaBits) on the Everspin and 2048K on the Avalanche which is the full amount of memory on both. Is it possible that you're mistaking MegaBits for MegaBytes or are we mistaken here?
from pico-sdk.
@Mikefly123 ah yes what a silly mistake on my part. 512Kbytes == 4Mbits. Thank you for catching that.
@wrong-formatt glad my notes were able to help you! But to be clear about my crude flash_range_erase
mods above: that chunk of code should never ever be used for anything beyond convincing yourself the MRAM chip is functioning. What I show there is dynamically allocating a byte array (of any size) each and every time flash_range_erase
is called. This is a big no no. -- Now that you know your MRAM is working, you can likely put the entire flash_range_erase
function back the way it was originally and see how your end application behaves. Like I mentioned prior, I preemptively added this avoid worrying about possible filesystem checks assuming the state of "erased blocks" for checksums or alignment or something. Give it a go and report back with what you find.
from pico-sdk.
I forgot to mention that I never added the flash_range_erase
function since I wasn't sure what it did at the time. The only changes we made to the firmware was changing the boot stage2 to Generic03h, clocking the QSPI bus to a slower value, and changing the flash size. Even if our firmware worked with these changes without adding the entire flash_range_erase
function, how would we be able to check to see if there were any filesystem checks? I just want to make sure that everything is working as intended.
from pico-sdk.
Also @maholli if you don't mind me asking. I just wanted to ask about building CircuitPython (I was looking through CircuitPython directories and saw your contributions to the PyCubed directory). We are currently trying to build CircuitPython on the flight controller board running the Avalanche AS3016204-0108X0PSAY (as Michael previously stated). However, I do not think CircuitPython supports the Avalanche MRAM (looking through the nvm.toml directory, the only existing supported MRAM I could find was the Everspin MR2xh40).
I have created my own custom .toml file specifically for the Avalanche AS3016204-0108X0PSAY following the .toml template that was supplied by Adafruit. However, when I flash the firmware.uf2 file onto the board, no drive shows up. I have also adjusted the pins and configured the other files within the custom board CircuitPython files. Is there anything you would suggest in order to resolve this issue? I really appreciate the help you've given us the entire way.
from pico-sdk.
@wrong-formatt that's a question for the circuitpython repo.
Nevertheless, it's been years since I wrote the circuitpython MRAM driver and they've made lots of infrastructure changes since then so I don't have any insight for you, sorry! What I can say is that in its default configuration, your Avalanche part should behave exactly like the Everspin MRAM. Maybe try building for the MR2xh40 part (despite have the Avalance part installed) and see how it goes.
from pico-sdk.
Related Issues (20)
- My offer
- Add tracking of peak allocated bytes by malloc
- spi_set_baudrate does not work well for SPI slave functionality
- __not_in_flash_func doesn't set noinline HOT 2
- Add support for UART stick parity
- Add board for Adafruit Feather RP2040 with USB Type A Host HOT 1
- Add ability to provide custom memory allocation for LWIP
- char vs unsigned char HOT 2
- Feature Request: gpio_get_irq_callback()
- Add board for 8086 USB Interposer HOT 1
- Linker warning "_getentropy is not implemented and will always fail" HOT 9
- Add PICO_PANIC_NO_STRINGS_ON_TARGET option HOT 6
- Faulty UART baudrate divisor formula HOT 1
- Boot loader application framework
- Missing handshake on control transfer
- Wrong data toggle HOT 1
- Can not find marco CLOCKS_PER_SEC in runtime.c HOT 1
- arm-none-eabi-g++ showing error in WSL HOT 2
- The operation couldn’t be completed. Unable to locate a Java Runtime that supports apt. Please visit http://www.java.com for information on installing Java. HOT 1
- Minor GCC 12 unused/unitialized warnings in 2.0.0
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pico-sdk.