Flash MEM through SPI not response

RE: Flash MEM through SPI not response

Einar Thorsrud — Tue, 19 Nov 2024 15:16:45 GMT

Hi,

I am glad to hear you got the basic communication working. I do not have any imediate suggestions for thy WEL bit, unfortunately.

Br,

Einar

RE: Flash MEM through SPI not response

SBou — Tue, 19 Nov 2024 10:28:29 GMT

HI,

After erase and program the microcontroller finally I reach read the device ID of the flash memory.

Now I have another problem that is that the flash memory is waiting the bit WEL change, and is here block in a "While" of my code.

/*! Function for checking that the Write Enable Latch is Active
 */
static void FLASH_Wait_For_WEL( void )
{
  while( !( FLASH_Read_Status_Register() &                                \
                    FLASH_SR_WRITE_ENABLE_LATCH_BIT ) ){
    k_msleep(5);
  }
}

After enable writing, this bit should be "1" but doesn't change.

When we have more info about this we ask you or open another tread.

Or if you have any suggestion we can study it.

Many thanks by your support.

Regards.

RE: Flash MEM through SPI not response

Einar Thorsrud — Mon, 18 Nov 2024 11:51:50 GMT

Hi,

Did you perform an erase all operation (for instance nrfjprog --recover) when you programmed the new firmware? That is requiered in order to erase the UICR and make the pin a GPIO again, as that configuration is persistent if you do not and earlier firmware enabled pin reset. If it still does not work, can you share the generated .config and zephyr.dts from your build folder so that we see which configuration is actually being used? Also, which SDK version are you using?

RE: Flash MEM through SPI not response

SBou — Mon, 18 Nov 2024 11:42:28 GMT

Hi Mr. Einar.

I tried the same code on test board nRF52 DK adding the parameter on the .overlay file (/delete-property/ gpio-as-nreset;) but when I cross the MISO pin P0.20 and MOSI pin P0.21 to read the data I send the uC fall down because the pin P0.21 still configurated as reset.

About the &spim description in overlay file for the &spi0 also has the same parameters but this works fine.

Could you provide another soultion or explain better how configure the parameters for &spim2?

Regards.

RE: Flash MEM through SPI not response

Einar Thorsrud — Wed, 06 Nov 2024 08:13:53 GMT

Hi,

I see. With that using the P0.21 should be OK as long as you have done a recover/erase all to clear the UICR (you can always read back the PSELRESET registers from a debugger to verify that it is the case). However, the overlay file does not properly describe the spim instance used for the external memory? You would want something similar to what is shown in this file.

RE: Flash MEM through SPI not response

SBou — Tue, 05 Nov 2024 10:46:01 GMT

Hi,

This is the overlay text file:

// To get started, press Ctrl+Space to bring up the completion menu and view the available nodes.

// You can also use the buttons in the sidebar to perform actions on nodes.
// Actions currently available include:

// * Enabling / disabling the node
// * Adding the bus to a bus
// * Removing the node
// * Connecting ADC channels

// For more help, browse the DeviceTree documentation at https://docs.zephyrproject.org/latest/guides/dts/index.html
// You can also visit the nRF DeviceTree extension documentation at https://nrfconnect.github.io/vscode-nrf-connect/devicetree/nrfdevicetree.html

&spi0 {
    status = "okay";
    compatible = "nordic,nrf-spim";
};

&spi1 {
    status = "disabled";
};

&spi2 {
	status = "okay";
    compatible = "nordic,nrf-spim";
};

&i2c1 {
    status = "okay";
    compatible = "nordic,nrf-twim";
};

&i2c0 {
    status = "disabled";
};

&flash0 {
	partitions {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "fixed-partitions";

		
		/* Set 3Kb of storage at the end of the of 2Mb flash 0 */
		/*
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0xf8000 DT_SIZE_K(3)>;
		};
		*/
	};
};

&power {
    status = "disabled";
};

&uart0_sleep {
    group1 {
        psels = <NRF_PSEL(UART_TX, 0, 6)>, <NRF_PSEL(UART_CTS, 0, 7)>;
    };
};

&uart0_default {
    group1 {
        psels = <NRF_PSEL(UART_TX, 0, 6)>, <NRF_PSEL(UART_CTS, 0, 7)>;
    };
};

&uicr {
    /delete-property/ gpio-as-nreset;
    status = "okay";
};

And still not works.

RE: Flash MEM through SPI not response

Einar Thorsrud — Tue, 05 Nov 2024 10:04:27 GMT

Hi,

The DK devicetree files will by default configure the pin as a reset pin. As you are using the the DK files with an overlay, you need to also then delete the gpio-as-nreset property as shown in this post.

RE: Flash MEM through SPI not response

SBou — Tue, 05 Nov 2024 09:37:33 GMT

Hi Einar, thanks for your support.

This is the devitree:

The P0.21 hasn't any assignament.

This is the Kconfig file and doesn't has the CONFIG_GPIO_AS_PINRESET.

source "Kconfig.zephyr"

menu "Proxximos Anchor Kconfig"

config CONNECTION_IDLE_TIMEOUT
	int "Time to be waited for a station to connect"
	default 30

config SSID
	string "SSID"
	help
		Specify the SSID to connect

choice KEY_MGMT_SELECT
	prompt "Security Option"
	default KEY_MGMT_WPA2

config KEY_MGMT_NONE
	bool "Open Security"
	help
	  Enable for Open Security

config KEY_MGMT_WPA2
	bool "WPA2 Security"
	help
	  Enable for WPA2 Security
endchoice

config PASSWORD
	string "Passphrase (WPA2) or password (WPA3)"
	help
	  Specify the Password to connect

config BUILD_DFU
	bool "Include DFU Configuration on the project"
	default n

if ARM_MPU
config MPU_ALLOW_FLASH_WRITE
	def_bool y
endif

endmenu

Normaly I use VS Code for programming and the Softreset is enabled on settings.

RE: Flash MEM through SPI not response

Einar Thorsrud — Mon, 04 Nov 2024 13:10:50 GMT

Hi,

I suspect that pin 0.21 is still configured as a reset pin. The default behaviour of the SoC is for the pin to be used as a GPIO, but several tools will default to configuring it as a reset pin in the UICR.

First of all, make sure you define it as a GPIO (or not a reset pin) in the devicetree. The Kconfig option CONFIG_GPIO_AS_PINRESET which had the same purpose is no longer used. This this post for more details on that.

Secondly, when you program with west from the command line or nRF Connect from VS Code, the default behaviour is also to enable pin reset at that stage. To avoid that, make sure to append "--softreset" if programming directly from west. And if programming from VS Code, make sure to edit the settings and enable. SoftReset. I prefer to search for the settings and then find the check-box that way: