Porting USB dongle with a copied application

[drollinger]

I am attempting to create an SPI communication to an ancillary circuit through an intermediary board and the nRF52840 USB dongle. If I start with the zephyr sample spi_flash and the nrf52840dk I can run and see the log files over the com port and USB. Now, if I have attached a nor flash to an intermediary board driven be the nRF52840 USB dongle, is there a best practices way to create the port. Unable to track the documentation to do this very common firmware development technique,  find a similar application and port it to the needed application, within the nrf SDK Zephyr amalgamation. It seems I can open v2.9.0 SDK from within the nrfconnect desktop into VSCode, copy an existing application out of the Zephyr/samples directory creating a stand alone application, pick the nrf52840dongle_52840 board, and add an overlay. 

Question: where are the syntax rules for an overlay for the nrf52840dongle_nrf52840? Would this be the only necessary edit to creating a nrf52840 USB dongle communicating qspi to a nor flash? 

Cy Drollinger

[Einar Thorsrud]

Hi,

Question: where are the syntax rules for an overlay for the nrf52840dongle_nrf52840? Would this be the only necessary edit to creating a nrf52840 USB dongle communicating qspi to a nor flash? 

Devicetree is a bit complex, but you can see an intro do it here. But in this case I suggest you refer to the devicetree files for the DK, and use that as a reference, and you can put that in an overlay file. The main parts here is the QSPI configuration which you can see an example of here (must be adusted if you have a different flash device):

&qspi {
	status = "okay";
	pinctrl-0 = <&qspi_default>;
	pinctrl-1 = <&qspi_sleep>;
	pinctrl-names = "default", "sleep";
	mx25r64: mx25r6435f@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 = [c2 28 17];
		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>;
	};
};

And the definition of the pins, from here:

	qspi_default: qspi_default {
		group1 {
			psels = <NRF_PSEL(QSPI_SCK, 0, 19)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO1, 0, 21)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>,
				<NRF_PSEL(QSPI_CSN, 0, 17)>;
			nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};

	qspi_sleep: qspi_sleep {
		group1 {
			psels = <NRF_PSEL(QSPI_SCK, 0, 19)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO1, 0, 21)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>;
			low-power-enable;
		};
		group2 {
			psels = <NRF_PSEL(QSPI_CSN, 0, 17)>;
			low-power-enable;
			bias-pull-up;
		};
	};

[drollinger]

Are these two files DevBrd.dts and DevBrd.dtsi and the specific hardware, qspi, merged into a single Brd.overlay? 

[Einar Thorsrud]

Hi,

Yes, in an overlay file you typically put it in the same file (it also ends up in the same zephyr.dts file in the build folder which is what is being used in the end regardless of if you have the devicetree configuration split across several files or not).

[drollinger]

GIven the definition of the pins, it would seem that I need to add the ampersand for both default and sleep?

[Einar Thorsrud]

Yes, if you put the definition in an .overlay file you need to use the ampersand (because you are refering to an existing node).