QSPI issue/questions

[Adam Gerken]

Hey everyone, I'm trying to use the QSPI module (again) to interface to RAM, not FLASH. I'm not really sure if this is possible, but we'll get there. Right now I can't get it to initialize.

So far I can't even get the qspi module to initilize, nrfx_qspi_init always returns 0x0000000d which I don't even see on the list of possible errors. Any ideas where this is coming from?

    //INITIALIZE THE QSPI
    nrfx_qspi_config_t config = NRFX_QSPI_DEFAULT_CONFIG;

    config.pins.sck_pin    = RAM_QSPI_SCK_PIN;
    config.pins.csn_pin    = RAM_QSPI_CS1_PIN;
    config.pins.io0_pin    = RAM_QSPI_IO0_PIN;
    config.pins.io1_pin    = RAM_QSPI_IO1_PIN;
    config.pins.io2_pin    = RAM_QSPI_IO2_PIN;
    config.pins.io3_pin    = RAM_QSPI_IO3_PIN;
    config.prot_if.readoc     = 0b00000011;
    config.prot_if.writeoc    = 0b00000010;

    nrfx_qspi_uninit();

    err_code = nrfx_qspi_init(&config, qspi_handler, NULL);
    APP_ERROR_CHECK(err_code);

I've tried it without changing any parameters, just boot up, run the nrfx_qspi_init with the defaults in the sdk_config and it still throws the same error. QSPI can use any pins on the chip, right?

Second, once I get that going, can I even use this module with a custom readoc and writeoc commands? I know the sdk is set up only to deal with flash but I should be able to write in whatever commands I want there, and it should communicate with the RAM just fine, no?

The RAM is a Microchip 23LC1024, wired up like a standard QSPI flash, I just need to use these commands when writting/reading:

sdk is 15.2.0 

[Shahar]

An interesting question.

AFAIK you are correct assuming the nrfx_qspi module is only for handling QSPI flash module, and expects the module to respond to the QSPI op codes.

But I don't think there's any limitation on you taking the nrfx_qspi, renaming it, and modifying the code to utilize the nrf_qspi functions with your new op codes.

You'll probably only need to implement read and write, and maybe KISS by having everything done in blocking mode (as it's RAM ... and maybe no need for erase or long write/read operations)

[haakonsh]

I suggest you use the QSPI HAL directly and write your RAM driver on top of that. The QSPI driver is written for FLASH devices and you will have to remove most of the code from it anyways in order to port it to RAM. 

[Adam Gerken]

Haakonsh, That's what I'm thinking too. I'll plug away on it and let you know if I run into any issues.

[Shahar]

The nrf_qpsi which I suggested to use are the QSPI_HAL btw...

I suggested to take nrfx_qspi and as the template - as it'll give structure, and most of the stuff might be ready already (just strip away anything to do with Flash, like erase, etc.)

[Adam Gerken]

Alright Haakonsh, I think I ran into a game stopper. The RAM wants the commands sent on all four data lines not just one, which I don't see how to make happen. Any ideas?

RAM:

NRF:

RAM:

NRF:

[haakonsh]

I think that's a hard one. 

The only solution I can think of is to manipulate the CLK and I/O lines with GPIOs during the instruction/command phase. 
That would require an external multiplexer between the QSPI and RAM device.
The idea is to mask the first 6 clock cycles and injecting the instructions on the last 2. 

It might require execution priority on the CPU during that time in order to bit-bang the instruction. 

[Adam Gerken]

That stinks. I'll probably just revert to SPIM mode. I wish the QSPI module was more flexible. Thanks.