Yes, PSRAM good choice for LA. Also for PWM/PDM. Only need check maximum speed.
2 Likes
Wow! Is this the first BP5+ third-party board?
@ian ā¦ for PSRAM, there is significant difficulty in auto-detection of PSRAM. I had a long-running issue thread with the Espressif folks about this on Github, begging them to simply reserve a few bytes of OTP to store the PSRAM settings in an Espressif-defined location, so that a common bootloader could be used for both PSRAM and non-PSRAM chips. (lots of requests for this, not just me)
If integrating this, it should be one of the things added to the OTP directory information added during manufacturing. Then, the code can use the PSRAM (or not) based on the stored OTP data.
1 Like
Would these kinds of issues also affect the BusPirate or isnāt this something that just affects the Espressif chip architecture?
For example the RP2350 would always boot from the NOR flash, no matter what, because the chip select of the PSRAM would be disabled by default with a pullup. Only when the BP firmware is running it can decide if it wants to use the PSRAM for some feature like the logic analyzer.
And please forgive me my ignorance - but wouldnāt the BP firmware then be able to autodetect it? Like write something at an address and then try to read it back? If there were no PSRAM you should get back all zeroes or ones, depending if you used pullups or pulldowns on the data lines.
1 Like
No problem putting the capacity in OTP, but it would make upgrades hard when the 128MBIT version is released.
No problem doing a test write and read out of range either.
The PSRAM specced supports the 0x9f read ID command and responds with a manuf. ID (0x0D), KGD (?, 0x5d), density code (0b010, and a long EID (undefined? unique chip id?). I checked the 16MBIT version and the density code is indeed different (0b000), however I do not know how easy it is to get the 9f info (SPI mode only) when the chip is initialized as part of the QSPI/RP address space.
This is probably very similar to when you want to read the ID codes of the NOR flash (which I already have programmed myself): you disable the XIP, send some commands manually and then re-enable the XIP again. The code for doing so must be loaded into ram first, because you canāt access XIP mapped code while XIP is disabled.
So this is mostly about linking functions into the correct sections and ensuring that no other function is running on the other core or irqs while doing so.
1 Like
Not capacity ā¦ it was the PSRAM bus type. Found the issue I opened.
We failed to persuade...
As is obvious from the thread, I first failed to explain that I was only asking them to reserve an official set of OTP fuses, so that the community could improve the situation. Unfortunately, they misunderstood the request as asking them to burn the OTP at factory.
Later, when the understood the request was to reserve the OTP fuses, they failed to understand how setting this in OTP was better than just writing the proper firmware to the device.
Folks from many projects (Tasmota, ESPEasy, WLED, etc.) tried to express the usefulness of having a single bootloader.
In the end, Espressif did not understand the benefit this would provide at essentially zero cost to them.
So, itās not the capacity ā¦ it also had to do with the type of the PSRAM (QSPI vs. OSPI) and the type of the flash (QSPI vs. OSPI). Thereās a separateissue on that topic. But the short version: To have a single bootloader (or other binary) supporting many chip + FLASH + PSRAM options, itās essentially mandatory to store at least the bus type for each in the OTP.
2 Likes
Ok, I see.
But for the BP there is no external bootloader, we are using what RasPi provides and limit the types of NOR flash supported. In the full firmware we have enough space and time to do more elaborate probing regarding PSRAM.
SPI, QSPI, OSPI,ā¦ all start out as regular SPI before the more advanced modes are activated and have a very basic, but common command set - at least to my knowledge. So for example the 0x9f read ID command should work on all of them. Based on the result you should be able to implement a small decision tree that arrives at the correct parameters to talk to the memory.
It is not that Iām against reserving space for this - when you rely on this kind of data being correct it complicates manufacturing because you have to be 100% sure to program the correct values. And you canāt change the data later (it is OTP), so the user canāt replace one part with another, even if the firmware would be capable of using it.
So I would prefer the firmware probing approach over a OTP approach unless we find one part combination where it doesnāt work.
1 Like
@Alex - I started a new firmware branch bp7r0 with updated platform, board and cmake files.
1 Like
I understand your point about limited hardware to support.
Iām not sure being able to probe the device using SPI means the problem would be solved. While SPI, QSPI, and OSPI are all regular SPI at first, the chipās response does not indicate whether pins were allocated and attached on the board. This requires a board-level source of information. Currently, itās hard-coded at compile time, requiring distinct firmware for each board.
Long-term, that can change with OTP, such that all RP2350 chips use the same firmware, loading pin mapping tables from OTP. A single firmware for BP5XL, BP6, BP7, ā¦ reduces situations where the user has the bad experience of burning the wrong thing to the device.
Thereās even some open-source semi-standard method to list which pins do what ā¦ something I was holding off on suggesting until the current OTP work is stabilized. (Iāll look for it and post a linkā¦)
If itās a shared goal to reduce the count of firmware images, then the foundational work being done now with OTP storage and OTP factory customization is key to enabling that future.
2 Likes
In theory I find this a nice goal, but in practice I think individual firmwares are preferable.
When we relocated some of the display driver pin between 5Rev8 and 5Rev9 I thought about unifying the firmware. This would require a if then else or case switch on some really critical stuff (display DP, display CS) which adds a lot of clock ticks for mundane tasks.
This could be mitigated by moving these things into PIO and just assigning the pins differently, but thatās a whole other can of worms. Not necessarily a bad one, but itās a broad discussion with system wide implications. Especially on the RP2350B chips, where the PIO range is split in two.
1 Like
You are right ā¦ this is a larger discussion / issue. The good news is that this is a far-future question, and thus practical needs will likely prevent any serious move in that direction.
There are solutions...
First, this doesnāt mean Iām pushing for consolidating to fewer firmware.
Where thereās truly time-critical functions, there are often still solutions. One relatively clean option, as an example, would be to write unique functions for those different pin configurations. Then, a single function pointer can be set to one or the other function, based on which board the firmware is on. It would not be nothing, but itād be close ā¦ maybe close enough.
Other less clean hacks also are immediately called to mind, but ā¦ all of this is moot, except to understand itās at least possible. And maybe you just decide itās not relevant for the target customer base, and the occasional wrong-firmware-experience is OK. All of thatās moot until itās a real question ā¦ which definitely isnāt yet. 
Then again, maybe a single āuberā firmware when āreleasesā become a thing ā¦ just so folks can copy the same UF2 binary onto each of their BP6+ boards ā¦ and it works on all of them. A few ways are available for this to work on RP2350, even where each board normally has its own firmwareā¦
But, definitely something to table (maybe forever).
1 Like
Thatās a good point, it can be more sophisticated than a case switch Sometimes I think too small
SparkFun has an extended PICO library that handles size detection and configuration of PSRAM on RP2350. It also has memory allocation and some other useful stuff, and is already targeted at the PSRAM chip weāre using:
The SparkFun RP2350 boards us the PSRAM IC which is detailed here
These functions are exported from the file sfe_psram.h
Setup
size_t sfe_setup_psram(uint32_t psram_cs_pin);
This function is used to detect the presence of PSRAM on the board and return the size of the PSRAM available. If no PSRAM is detected, a value of 0 is returned.
1 Like