SPI NOR peripheral restart

[PieterJericho]

Hi 

I have an external NOR flash chip which is powered off on startup. The idea is to power up the flash when needed to reserve power. On startup, I get the error message:

<err> spi_nor: SFDP magic ffffffff invalid
<err> spi_nor: SFDP read failed: -22

Enabling the power pin only starts during application code, meaning SPI-NOR fails before that.

Is there a way to restart the SPI-NOR instance or driver to re-attempt initializing the device?

I have had limited success by reorganizing boot priorities to have GPIO start before SPI, but what about the case where I have to reinitialize during runtime?

I have also tried remounting the fstab entry, but it doesn't seem to do anything to the SPI situation.

I appreciate any guidance regarding this

[Vidar Berg]

Hi,

Did you try to set the pin similar to how it is done in this board file for the Thingy:52 : https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/arm/thingy52_nrf52832/board.c? I would have expected this work as long as the gpio init priority had higher than the priority used by the SPI driver init. Or maybe the flash needs more time to power up.

Is there a way to restart the SPI-NOR instance or driver to re-attempt initializing the device?

It should be possible to use Zephyr's Device Power Management Infrastructure for this (enabled through CONFIG_PM_DEVICE=y). For instance, you can run pm_device_action_run(spi_dev, PM_DEVICE_ACTION_SUSPEND); if you want to suspend the driver during an idle period.

Here is how this action is implemented in the driver port layer: https://github.com/nrfconnect/sdk-zephyr/blob/482dcc7865f7d3a458f061a1d8276c5801eed1e4/drivers/spi/spi_nrfx_spim.c#L460

Best regards,

Vidar

[PieterJericho]

Hi Vidar Berg 

Thanks for the response. Although the calls work, it does not reinitialize the children, like the jedec,spi-nor.

&spi2 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	sck-pin = < 13 >;
	mosi-pin = < 16 >;
	miso-pin = < 17 >;
	cs-gpios = <&gpio0 19 GPIO_ACTIVE_LOW>;
	label = "FLASH";

	exflash0: exflash@0 {
        supply-gpios = < &gpio0 12 GPIO_ACTIVE_LOW >;

		status = "okay";
		compatible = "jedec,spi-nor";
        sfdp-bfp = [ 53 46 44 50 06 01 02 ff ];
		reg = <0>;
        requires-ulbpr;
		hold-gpios = < &gpio0 14 GPIO_ACTIVE_LOW >;
		wp-gpios = < &gpio0 15 GPIO_ACTIVE_LOW >;
 		jedec-id = [bf 26 42];
		label = "EXFLASH0";
		size = < 33554432 >;
		spi-max-frequency = <40000000>;
		//spi-max-frequency = <1000000>;
	};
};

I have tried doing the same to the EXFLASH0 device as shown above, but it fails to suspend/resume.

[Vidar Berg]

Hi,

Sorry, you are right, I see now that the PM device APIs are only implemented for the spim driver, not the spi nor driver. I think the easiest way around this is to manually call spi_nor.c:spi_nor_init() from the application after issuing the pm resume action.  

#define EXFLASH0_NODE_ID DT_NODELABEL(EXFLASH0)

#if DT_NODE_HAS_STATUS(DT_NODELABEL(EXFLASH0), okay)
const struct device *flash_dev = DEVICE_DT_GET(EXFLASH0_NODE_ID);
#else
#error "Node is disabled"
#endif

...

err = spi_nor_init(flash_dev);
...

[PieterJericho]

Hi Vidar Berg 

The spi_nor_init function is not public API, but I removed the static qualifier and got it linked. It does reinitialize the SPI indeed, however when mounting littlefs with the DT-defined mountpoint, it says it cannot find the EXFLASH0 device. I also couldn't get the device with device_get_binding, because the device was uninitialized during boot.

I assume the same occurs within the fstab-defined mountpoint, and hence it doesn't mount:

<err> littlefs: can't get flash device: EXFLASH0

[Vidar Berg]

It's difficult to properly test this on my end with the dev kits I have. But I see you tagged the ticket with nrf52840, is it an option to use the QSPI? The QSPI NOR driver supports PM device states and will put the flash IC into DPM (deep power-down mode) on suspend.

[PieterJericho]

Unfortunately, I have the SST26VF032BT-104I/SM, which has QSPI disabled on power-up. I couldn't get quad-enable-requirements to work, but in retrospect, perhaps using the resume/suspend workflow it could work. Or is that not what quad-enable-requirements are for?

ww1.microchip.com/.../SST26VF032B-SST26VF032BA-Data-Sheet-DS20005218J.pdf