Including Wiznet5500 files on the NRF52840DK using VSCode

[Sebastiaan]

Hello,

I am currently integrating the Wiznet5500 drivers into a VSCode project, but I am stuck on where to include these custom modules.

In the previous version in SES (Segger Embedded Studio) these files could be included in the Options --> Preprocesssor --> include paths

Thanks in advance,

Sebastiaan

[Priyanka]

Hi Sebastiaan,

You should follow the standard west module procedure as described here, in order to do this.

The extension will pick up this as soon as west registers it.

P.S There should also be a Wiznet5500 driver already included in Zephyr as "w5500".

Kind Regards,

Priyanka

[Sebastiaan]

Hi Priyanka,

Thanks for the reply. I am currently trying to implement the w5500 driver as per your suggestion.

Is it correct then I only have to include "CONFIG_ETH_W5500=y" to my prj.conf file to include the library?

Also, are there any example projects which use this library?

Thanks in advance,

Sebastiaan

[Priyanka]

Hi Sebastian,

Unfortunately there are no examples of this at the moment.

Regards,

Priyanka

[Sebastiaan]

Hi Priyanka, 

No worries.

I however came across some issues when flashing the included files to the NRF52840DK.

I configured the SPI and W5500 according to my needed pinout (i left out the <> due to the code block)

&spi3 {
	sck-pin = 47;
	miso-pin = 46;
	mosi-pin = 45;
	cs-gpios = &gpio0 44 GPIO_ACTIVE_LOW;
	status = "okay";
	w5500: w5500@0 {
					compatible = "wiznet,w5500";
					label = "w5500";
					reg = 0;
					spi-max-frequency = 1000000;
					int-gpios = &gpio0 20 GPIO_ACTIVE_LOW;
	};
};

However, when flashing this I noticed the following output on the terminal:

11:05:13.235 -> E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
11:05:13.235 -> E: Current thread: 0x200022f0 (main)
11:05:13.235 -> E: Resetting system
I: nRF5 802154 radio initialized
11:05:13.492 -> ASSERTION FAIL @ WEST_TOPDIR/zephyr/include/drivers/gpio.h:752
11:05:13.526 -> E: r0/a1:  0x00000004  r1/a2:  0x000002f0  r2/a3:  0x00000000
11:05:13.526 -> E: r3/a4:  0x2000dc1d r12/ip:  0x00000000 r14/lr:  0x0000bd2b
11:05:13.526 -> E:  xpsr:  0x61000000
11:05:13.526 -> E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
11:05:13.526 -> E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
11:05:13.562 -> E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
11:05:13.562 -> E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
11:05:13.562 -> E: fpscr:  0x00053388
11:05:13.562 -> E: Faulting instruction address (r15/pc): 0x000486d2

Do you know what could be the cause of this?

With kind regards,

Sebastiaan

[Priyanka]

Hi,

It seems like the assert _ASSERT(..) is triggered. You could try to set a breakpoint on this assert and try following the pin assignment back to the call stack to see the problem.

Also, which version of nRF Connect SDK are you using? I would recommend using the latest version. (v1.8.0).

Regards,

Priyanka

[Sebastiaan]

Hello Priyanka,

The issue is caused by the following line:

cs-gpios = <&gpio0 44 GPIO_ACTIVE_LOW>;

My initial thought was that it has to do with the gpio0 being limited to the 0-32 range and the pin number 44, so I changed it to gpio1 but the issue is still there. However, there is no issue with 

<&gpio0 21 GPIO_ACTIVE_LOW> (no kernel panics), but as mentioned before pin 44 is required

 

Any ideas?

Thanks,

Sebastiaan

[Priyanka]

Hi Sebastian,

First of all, what is the status of your gpio1? Is the status = "okay"? Then, if this is okay, could you try with any of the following:

In case you wish to use the P1.12, you could try ,

cs-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; or,

cs-gpios = <&gpio0 43 GPIO_ACTIVE_LOW>; 

In case you wish to use the P1.13, you could try ,

cs-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;  or,

cs-gpios = <&gpio0 44 GPIO_ACTIVE_LOW>;

As you mentioned about the range , it is a range of 0-31 (a total of 32). So I guess you could try any of these configuration.

Kind Regards,

Priyanka

[Sebastiaan]

Hi Priyanka,

This has indeed fixed the kernel panic. I am currently trying to initiate the w5500 using the zephyr drivers but I am lost in how to include the eth_w5500 file.

I also included the uart driver and this driver shows up (which is under drivers/uart.h) and is able to send and receive data via interrupt.

The ethernet driver is under drivers/ethernet/eth_w5500.c and does not show up and it is configured in the device tree aswell.

Hopefully it is clear what I am trying to explain.

Thanks in advance,

Sebastiaan

[Priyanka]

Hi Sebastian,

Kindly take a look at this ticket.

Regards,

Priyanka

[Sebastiaan]

Hi Priyanka,

As far as I understood from the ticket, the W5500 is a Zephyr driver (and not an external one, so no extra CMakeList arguments are required). So as I have already done I need to set the configurations in my prj.conf file as the following:

CONFIG_SPI=y
CONFIG_NETWORKING=y
CONFIG_NET_L2_ETHERNET=y
CONFIG_ETH_W5500=y

And add an overlay in nrf52840dk_nrf52840.overlay for the spi3 driver matching the pins as following:

&spi3 {
	sck-pin = 47;
	miso-pin = 46;
	mosi-pin = 45;
	cs-gpios = &gpio1 12 GPIO_ACTIVE_LOW;
	status = "okay";
	w5500: w5500@0 {
					compatible = "wiznet,w5500";
					label = "w5500";
					reg = 0;
					spi-max-frequency = 1000000;
					int-gpios = &gpio0 20 GPIO_ACTIVE_LOW;
	};
};

I can see in the compilation that the w5500 driver is being built.

[190/223] Building C object zephyr/drivers/ethernet/CMakeFiles/drivers__ethernet.dir/eth_w5500.c.obj

The ticket mentioned does however not describe on how to access the driver functions itself.

Thanks in advance,

Sebastiaan

[Priyanka]

Hi Sebastian,

You could try including CONFIG_ETH_W5500=y in your prj.conf. This will include the source file. And you will also have to add the header in your main.c file.

Regards,

Priyanka