Write protection pin for External SPI Flash configuration

[Riccardo Gaiati]

Hi,

i am working with nRF5340, nRF Connect SDK 1.9.1 and an external SPI Nor Flash.

The configuration in the device tree is the following:

/* External flash  */
&spi4 {
	label = "spi-ext-flash";
	compatible = "nordic,nrf-spim";
	status = "okay";

	sck-pin = < 17 >;
	mosi-pin = < 13 >;
	miso-pin = < 14 >;
	cs-gpios = < &gpio0 18 GPIO_ACTIVE_LOW >;

	mx66: mx66u1g45g@0 {
		compatible = "jedec,spi-nor";
		label = "MX66";
		reg = <0>;
		spi-max-frequency = <16000000>; /* Max frequency achievable with nRF5340 at 64Mhz */
		size = <1073741824>;	/* Size in bit set to 1 Gb (128 MBytes) */
		wp-gpios = < &gpio0 15 GPIO_ACTIVE_LOW >;
		enter-4byte-addr = <0x85>;
		has-dpd;
		t-enter-dpd = <10000>;
 		t-exit-dpd = <30000>;
		jedec-id = [c2 25 3b];
	};
};

I do not see any activity on the Write Protection pin when the code is run.

Could you please give me a feedback regarding the configuration of the writep protection and reset pin defined in the device tree file ?

Is any code generated if those pin are declared in the device tree file ?

Thanks in advance for the help !

[Simonr]

Hi

What driver exactly are you referring to here? Write protection needs to be disabled before writing to the flash and is done either in the SPI driver you use or in the main.c of the application.

Best regards,

Simon

[J.P. Hutchins]

Hi Simonr , I presume that the driver is spi_nor.c.  In it we can see that neither the write protect pin or the hold pin are implemented.  The only Zephyr flash driver I see that uses the wp_gpios pin is spi_flash_at45.c.  It seems that none of them use hold_gpios.

It seems that in the simple case, spi_nor.c should be patched to set both pins as GPIO_OUTPUT_INACTIVE (typically high for these wp and hold pins).

Next, it's reasonable to initialize WP active and only de-assert during flash writes.  Could still be done with spi_nor.c simply following the model from spi_flash_at45.c.

The hold pin I'm not so sure about because the use case is more complicated.  If I understand correctly, it is intended to create a mechanism by which the SPI transaction is preempted by another SPI transaction.  Would appreciate your thoughts on scope + cost/benefit.

Cheers,
J.P.