H743 Nucleo boards

[dresco]

Hi Terje,

Looks like I'll have two of the Nucleo H743ZI boards from Monday (back orders fulfilled from two suppliers), can I send you one?
If so, just let me know where to send it..

Cheers,
Jon

[terjeio]

I have been very busy lately so sorry for the late answer. I'll try to clear the issues backlog the coming days.

Thanks for the offer but IMO I believe it is best you keep the board as a backup? I have a large collection of different boards already and I am a bit hesitant to add to that since it might result in me providing support for the driver...

BTW is the low level lwIP driver provided for this chip any good? The F7xx driver is bad performance wise, IIRC an improved driver is to be released in Q2 or Q3. A good test is to time the transfer speed in check mode.

[dresco]

No worries, I appreciate the huge amount of effort you put into this project!

Yep - the latest ST package for the H7 included the rewritten Ethernet driver, so am using that. I hadn't got as far as any performance testing, but a very quick WS test just now shows roughly 10x improvement over default serial connection to the Nucleo for a large file (though that's still only ~1Mb/s). Do you have any benchmark files you use, else I'll just compare against Teensy performance?

To be honest, I was hoping that you would consider upstreaming the driver into the main repos - once I get it into a state that you are happy with. My motivation for the port was just to have something that gets close to Teensy performance, but with an improved development/debug experience.

[terjeio]

Do you have any benchmark files you use, else I'll just compare against Teensy performance?

I have a few files, some of which has been added to issues, but IMO just compare against the Teensy.

To be honest, I was hoping that you would consider upstreaming the driver into the main repos - once I get it into a state that you are happy with.

That may happen a bit later as I am considering adding you as a maintainer of the grblHAL repo. Generally speaking I do not want to add to my workload by taking over support for drivers and plugins written by others - the way grblHAL is written allows me to link to the repos containing the code instead.

[DnKon]

Hi! I cannot find H7 driver repo, are they supported?

[terjeio]

Look here.

[DnKon]

Thanks!

[dresco]

Hi @terjeio

Just curious - how is your Ethernet support in this F7 driver - is it stable for you?

My H7 port is using the rewritten ST code, but am seeing an odd issue which I still need to debug. (Not receiving responses to some '?' realtime status report commands - I think it is timing sensitive, as only with some jobs, and never in check mode).

[dresco]

Unfortunately has made no difference.

I also included the tcp_echoserver sample code into my build, just for testing, and that seems to maintain a solid data transfer (up to 80Mb/s) while running the same jobs over serial.

I think I'll merge what I already have in my usb and ethernet branches into my master, and just keep digging for the root of this..

[dresco]

Am getting there, wasn't a timeout / re-transmission after all.

My issue was that link_status_callback() doesn't get called during startup - only when the cable is removed or re-inserted. So linkUp was still zero, the poll functions for the services weren't being scheduled, and the stream handler functions were only being called intermittently by the send and receive callbacks.

Don't know if that will be the same for your F7 port - removing and re-inserting the cable should make a difference if it is?

Just looking at the logic of when the link_status and netif_status callbacks get invoked, one option might be to move the logic to the netif callback instead? But I have just run into another oddity that neither callback gets invoked when started with a static IP, so still digging...

[dresco]

Ah, not to worry. I notice you also set linkUp directly in enet_start(). Have changed my code to do something similar, and now seems to be working well for both DHCP and static IP..

[terjeio]

@dresco Does this mean your original issue went away?

[dresco]

@dresco Does this mean your original issue went away?

Yes, was all down to the poll functions not being scheduled as expected. Appears stable now, has been running in the background for several hours with no issues..

I've just updated my master branch to include Ethernet support for Nucleo builds, and SD card support (via SDMMC peripheral) for the WeAct board.

[terjeio]

@dresco I have made some changes to the networking code to reduce risk for a buffer overflow and add WebDAV support:

STM32F7xx/Src/enet.c

Line 54 in 131306e

static char netservices[NETWORK_SERVICES_LEN] = "";

STM32F7xx/Src/enet.c

Lines 146 to 154 in 131306e

	#if HTTP_ENABLE
	if(network.services.http && !services.http) {
	services.http = httpd_init(network.http_port == 0 ? NETWORK_HTTP_PORT : network.http_port);
	#if WEBDAV_ENABLE
	if(network.services.webdav && !services.webdav)
	services.webdav = webdav_init();
	#endif
	}
	#endif

and for enable WebDAV

STM32F7xx/Inc/my_machine.h

Line 85 in 131306e

//#define WEBDAV_ENABLE 1 // webdav protocol - requires http daemon and SD card enabled.

There is also a new function required for WebUI support but I guess you have already implemented that:

STM32F7xx/Src/enet.c

Lines 83 to 114 in 131306e

	network_info_t *networking_get_info (void)
	{
	static network_info_t info;
	memcpy(&info.status, &network, sizeof(network_settings_t));
	strcpy(info.status.ip, IPAddress);
	if(info.status.ip_mode == IpMode_DHCP) {
	*info.status.gateway = '\0';
	*info.status.mask = '\0';
	}
	info.is_ethernet = true;
	info.link_up = linkUp;
	info.mbps = 100;
	info.status.services = services;
	struct netif *netif = netif_default; // netif_get_by_index(0);
	if(netif) {
	if(linkUp) {
	ip4addr_ntoa_r(netif_ip_gw4(netif), info.status.gateway, IP4ADDR_STRLEN_MAX);
	ip4addr_ntoa_r(netif_ip_netmask4(netif), info.status.mask, IP4ADDR_STRLEN_MAX);
	}
	sprintf(info.mac, "%02X:%02X:%02X:%02X:%02X:%02X", netif->hwaddr[0], netif->hwaddr[1], netif->hwaddr[2], netif->hwaddr[3], netif->hwaddr[4], netif->hwaddr[5]);
	}
	return &info;
	}

[dresco]

fwiw - latest code gives a compilation error when building for F7 with SDcard and HTTP enabled

../networking/httpd.c: In function 'http_init_file':
../networking/httpd.c:1931:17: error: 'vfs_file_t' has no member named 'is_custom_file'
 1931 |         if (file->is_custom_file && (file->data == NULL))

[terjeio]

Oops, I forgot to commit the .cproject file:

Set the LWIP_HTTPD_CUSTOM_FILES symbol to 0 to fix.

[dresco]

Thanks..

[dresco]

Btw, I notice there were some additional LwIP memory/buffer settings added to the symbols, did they have much effect?

[terjeio]

Btw, I notice there were some additional LwIP memory/buffer settings added to the symbols, did they have much effect?

Can't remember now - I believe I "inherited" the settings from a project I used as a template for the telnet daemon.

[dresco]

I saw the benchmarking thread on the ESP3D GitHub repo. Have just done a quick H7 test, and am seeing about 1MB/s download (is using the new ST driver) - upload is not writing any data to the card.

SDMMC and ETH peripherals are using DMA, but they're not currently using the same memory regions - so all data is going through a scratch buffer anyway. Will try to fix that...

[terjeio]

... upload is not writing any data to the card

From the WebUI or from ftp and/or webdav (or all)? Any errors?

[dresco]

Hmm, looks like writes from all interfaces are failing, and possibly corrupting the card too. Think I need to revisit my SDMMC code..

[dresco]

Fix has been committed for my card corruption issues on writes (dma+cache coherency again). Have since uploaded & downloaded hundreds of MB through WebDAV, and all checksums okay.

Performance is still poor, but have started looking into that & think there is plenty of room for improvement. Is falling back to single sector requests for a multitude of reasons - reminds me of the saying "there are a million ways for it it to go wrong, but only one way for it to go right"!

[dresco]

Hi @terjeio

I've been doing a bit more work on networked SD card performance in my local branch, and have got to about 2MB/s for reads and 750KB/s for writes (testing with WebDAV).

This is with a new 32GB SanDisk card, on a Nucleo dev board running at 480MHz, with 48MHz SDMMC clock. (Am also using an SD card breakout directly on the headers to avoid the need for jumper wires & slower SDMMC clock speeds).

The key seems to be trying to avoid small reads & writes via the SDMMC peripheral. These mostly happen when data is not correctly aligned for DMA access & the associated L1 cache maintenance operations.

I have had some success with this for the reads at least, but does need a patch to the networking plugin. Is this something you would consider? Will make a PR if you are agreeable, but just wanted to run the idea past you first..

Would like to do something like this;

diff --git a/httpd.c b/httpd.c
index 3fdfe74..0a336d1 100644
--- a/httpd.c
+++ b/httpd.c
@@ -1142,6 +1142,20 @@ static bool http_check_eof (struct altcp_pcb *pcb, struct http_state *hs)
             count = max_write_len;
 
  #endif /* HTTPD_MAX_WRITE_LEN */
+
+ #if defined(NUCLEO_H743) && L1_CACHE_ENABLE
+        /* Ensure read sizes are a multiple of 32 bytes, this helps maintain buffer alignment
+         * with L1 cache lines when performing sequential reads through a file.
+         *
+         * This results in less fallback to scratch buffer (single sector) reads, and provides
+         * a 2x read performance improvement when testing on STM32H7.
+         */
+        if (count & 0x1F) {
+            count = count & ~0x1F;
+            //printf("http_check_eof(), count adjusted to 32byte length - %i bytes\n", count);
+        }
+ #endif
+
         do {
             if ((hs->buf = (char *)mem_malloc((mem_size_t)count))) {
                 hs->buf_len = count;

Edit: obviously wouldn't make it Nucleo specific as above, is just my current code..

[terjeio]

A PR for this will be accepted - but make it processor specific instead of board specific?
Perhaps I should try the same for the iMXRT1062 - interesting that you gained a 2x speedup.