nrf5340 QSPI multiplexing

currently this is more of a theoretical question, but i have an idea of something that might utilize this (3 QSPI devices)



Ive been looking at the Nrf5340 and the nrf7002 that both use QSPI

I've also noted that it appears, unless I'm mistaken, you cant implement matter without external memory


I have noticed the existence of 6 channel multiplexers e.g TS3A2718E

and displays that also use QSPI e.g ones based on EVE4 BT817Q such as RVT50HQBFWCA0

As the n5340 only has one CS pin it is limited by itself to one device


ignoring the issue of shared bandwidth limits



It strikes me that it is at least theoretically possible to multiplex the bus using one, or more? TS3A2718E or similar devices 

e.g


the multiplexer(s) could be controlled via a single GPIO, as above
or and I2C/SPI GPIO Expander  e.g (gpio expander was just first in list)


 Assuming i haven't missed something ( i haven't found a suitable 3 port 6 channel multiplexer)

The some questions i can think of are

  1. does/could? zephyr/device tree allow SPI multiplexers with sub device nodes?

    e.g 
    &qspi {
            ...
            
            multiplexer {
            
            ....
            
                mx25r64: mx25r6435f@0 {
                reg = <0>;
                ....
        
        
                };
                
                nrf70: nrf7001@1 {
                reg = <1>;
                ....
                };
        };



  2. would the nrf5340 hardware have any issues with this (assuming the multiplexer defaults to the flash chip)?
  3. what considerations would have to be made for programming the flash?
  4. can/do the application/network cores share QSPI if using nrf7002?


    I'm thinking the driver would be relatively simple (pull up down pins to select correct device) but It would 
    something to tell it to do this, I'm not that familiar with kernel internals to know the specifics, but i believe spi controller drivers must do something similar for chip select, as is pulled low on the correct CS pin to select device    

    If there is a better place for this let me know 


    thx












     


Parents
  • Hi,

    I've also noted that it appears, unless I'm mistaken, you cant implement matter without external memory

    Just a technicality clarification for this: You can implement Matter without external memory, as the requirement is that dual bank OTA is a mandatory feature and this is what often triggers the requirement for an external flash. You may get away without an external flash on for instance the nRF54LM20 if you don't have WiFi. I.e the external flash is a requrirement due to another requirement.

    does/could? zephyr/device tree allow SPI multiplexers with sub device nodes?

    The Zephyr devicetree model, as currently implemented for Nordic's QSPI driver, does not natively support a multiplexer model with sub-device QSPI nodes. Each QSPI controller is expected to have a single flash device node, and multiplexing between multiple QSPI devices is not directly supported in the devicetree structure.

    would the nrf5340 hardware have any issues with this (assuming the multiplexer defaults to the flash chip)?

    1. answers this since it's not supported

    can/do the application/network cores share QSPI if using nrf7002?

    If you set up the nrf7002 with SPI then yes, they (i.e the app core) uses the QSPI to the external flash.

    I think I instead would choose a different approach and use the QSPI for the component that needs it (choose either 7002, external flash or display) and set up an SPI instance for the other two.

    For instance on the nRF7002DK, the QSPI is set up between the nRF5340 and nRF7002 and SPI is set up from the nRF5340 and external flash: https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/nordic/nrf7002dk/nrf7002dk_nrf5340_cpuapp.dts 

    In theory you should be able to chip select between what will use the QSPI, but the 7002 requires the QSPI/SPI peripheral at all time to my understanding

    Kind regards,
    Andreas

  • so might be theoretically possible but would at minimum require custom kernel and QSPI driver

    and can probably achieve similar by other means more practically 


    thx

Reply Children
No Data
Related