Configuration of custom flash memory for standard zephyr driver

[Yury Morgunov]

Hello!

I have a device on which the S25HL01GT memory is soldered. The problem is that I don’t understand how I should work with .dts in order for this memory to work with the standard driver from zephyr.

I added the following to the .overlay:

&qspi {
	status = "okay";
	pinctrl-0 = <&qspi_default>;
	pinctrl-1 = <&qspi_sleep>;
	pinctrl-names = "default", "sleep";
	s25h: s25hl01gt@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		/* MX25R64 supports only pp and pp4io */
		writeoc = "pp4io";
		/* MX25R64 supports all readoc options */
		readoc = "read4io";
		sck-frequency = <8000000>;
		jedec-id = [34 2B 1B 0F 03 90];
		sfdp-bfp = [
			e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
			ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
			10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 68 44
			30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
		];
		size = <67108864>;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;
	};
};

...

	aliases {
		spi-flash0 = &s25h;
	};

And I use the following code:

  const struct device *flash_dev = DEVICE_DT_GET(DT_ALIAS(spi_flash0));
	if (!device_is_ready(flash_dev)) {
		printk("%s: device not ready.\n", flash_dev->name);
		return 0;
	}

But it doesn't work and I don't understand how to debug such problems. I'm not even sure that the jedec-id is correct. When compiling into zephyr.dts, I see that for qspi there are two mx25r64 flash memories and my s25h is also in the list, is this bad? I tried to delete it via /delete-node/mx25r6435f; in &qspi but it didn't work.

Thanks in advance!

[Sigurd Hellesvik]

Hi,

Which version of the SDK do you use?

What error do you get exactly?

I recommend the JESD216 sample to read out info from your external flash.

Regards,
Sigurd Hellesvik

[Yury Morgunov]

Thank you! It seems this will be useful when preparing sfdp.
The flash memory is not responding, it seems to be caused by hardware problems, since I received a jedec-id from another board and another memory.

[Sigurd Hellesvik]

Yury Morgunov said:

The flash memory is not responding, it seems to be caused by hardware problems, since I received a jedec-id from another board and another memory.

Always good to have it narrowed down.

You probably know, but it is better to have said it too many times than too few: I suggest a logic analyzer or oscilloscope to probe the lines as a first step in debugging the HW issue.

[Yury Morgunov]

The problem is that the boards I use are in a bga package and there is no access to the contacts. For example, I would like to use uart instead of RTT, since uart is much more convenient, but I can’t.

And since I have little experience in the zephyr environment, it’s quite difficult for me to blindly configure the driver via dts.

But I figured out when the initialization of drivers begins, it became easier to understand.

However, it was new to me that flash memory has the sfdp standard, this both complicates and simplifies development, and I think the example you sent me will help me figure it out.

[Sigurd Hellesvik]

Yury Morgunov said:

The problem is that the boards I use are in a bga package and there is no access to the contacts.

Do you use your own custom board or some public board?

I'm thinking that if it is a public board I could maybe have a look at it and see if I got any ideas

[Yury Morgunov]

I'm using a custom board with a BL5340PA module. Inside it is an nrf in a bga case, just like an external flash memory. I'm not sure I can show it.

[Sigurd Hellesvik]

From what I can see, there is no external flash inside the BL5340PA, so I assume that external flash is on your custom board.

If we were to dabble in hindsight, we would say that a good idea would have been to add probe points for not-exposed signals on the test-PCB that you made. However all we can do with hindsight is to learn from it.

If you want, I can have a look at your custom PCB layout?
If so, make a private ticket and ask for a review. And link to the private ticket here, so I know about it.

Then, if we find something wrong in the layout, it may be hard to fix it in firmware. However, if everything looks good in the layout, I can continue to help you figure out why the firmware will not cooperate.

[Yury Morgunov]

Sorry for the short pause, I was waiting for the pcb files to find the required via on the board to connect the oscilloscope.

It seems the driver is not setting up the memory correctly. One of the data pins (DQ3_RESET#) is used as reset and it turns out there is 2.3V DC.

It is not clear why it has this particular meaning; there is nothing on the DQ3_RESET# signal track except the memory itself and nrf.

Jedec-id should have been read on one spi line and then started sfdp synchronization, right?

[Sigurd Hellesvik]

Yury Morgunov said:

Sorry for the short pause,

 No worries at all, I always have other users to answer.

Yury Morgunov said:

One of the data pins (DQ3_RESET#) is used as reset and it turns out there is 2.3V DC.

Try to configure the reset pin in Pinctrl to pullup/pulldown depending on what you need to not reset the external flash.

I suspect that our external flash driver does not have reset pre-configured.

If that works, we can look into if external flash drivers support reset pins or not.