Page 6 of 9

Re: [DEV] STM32H7xx support (new)

Posted: Mon Jun 29, 2020 5:14 pm
by mikeprotts
I've also tested as an MQTT client connecting to a local broker, seems fine so far. lwip stats not showing any errors.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Tue Jun 30, 2020 4:33 pm
by mikeprotts
Three hours into a modest stress test using http and mqtt, there are a few errors, but as the settings were tuned for a different workload (using the STM32F767) it's probably a lack of memory pool resources. The way I allocate lwip pools doesn't allow much headroom.

Code: Select all

lwip stats
>LINK   xmit: 1618744   recv: 1559684   fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 0
>ETHARP         xmit: 541       recv: 3162      fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 1341582
>IP_FRAG        xmit: 0         recv: 0         fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 0
>IP     xmit: 1618311   recv: 1556625   fw: 0   drop: 365       chkerr: 0       lenerr: 0       memerr: 0       rterr: 5        proterr: 363    opterr: 0       err: 0  cachehit: 0
>ICMP   xmit: 0         recv: 0         fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 0
>TCP    xmit: 1618377   recv: 1556325   fw: 0   drop: 1         chkerr: 0       lenerr: 0       memerr: 3       rterr: 0        proterr: 1      opterr: 0       err: 0  cachehit: 1504881
>MEM HEAP       avail: 0        used: 0         max: 5056       err: 0
>MEM RAW_PCB    avail: 4        used: 0         max: 0  err: 0
>MEM TCP_PCB    avail: 12       used: 12        max: 12         err: 15
>MEM TCP_PCB_LISTEN     avail: 2        used: 1         max: 1  err: 0
>MEM TCP_SEG    avail: 12       used: 0         max: 12         err: 0
>MEM REASSDATA  avail: 5        used: 0         max: 0  err: 0
>MEM FRAG_PBUF  avail: 0        used: 0         max: 0  err: 0
>MEM NETBUF     avail: 2        used: 0         max: 1  err: 0
>MEM NETCONN    avail: 12       used: 1         max: 7  err: 0
>MEM TCPIP_MSG_API      avail: 4        used: 0         max: 1  err: 0
>MEM SYS_TIMEOUT        avail: 5        used: 4         max: 4  err: 0
>MEM PBUF_REF/ROM       avail: 8        used: 0         max: 0  err: 0
>MEM PBUF_POOL  avail: 8        used: 0         max: 5  err: 0
>MEM MALLOC_64  avail: 2        used: 0         max: 1  err: 0
>MEM MALLOC_128         avail: 4        used: 0         max: 4  err: 10
>MEM MALLOC_256         avail: 1        used: 0         max: 1  err: 8
>MEM MALLOC_512         avail: 1        used: 0         max: 1  err: 6
>MEM MALLOC_768         avail: 8        used: 0         max: 8  err: 0
>SYS    sem.used:  2    sem.max:   8    sem.err:   0    mutex.used: 0   mutex.max:  0   mutex.err:  0   mbox.used:  2   mbox.max:   0   mbox.err:   6


I need to get my ADC and SPI code working (i.e. ported from the STM32F7 code) to generate my standard workload, which may take a while.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Tue Jun 30, 2020 5:30 pm
by Giovanni
You could try the same workloads on MACv1 if in doubt, that could hint to a problem.

Giovanni

Re: [DEV] STM32H7xx support (new)

Posted: Tue Jun 30, 2020 8:51 pm
by mikeprotts
Giovanni wrote:You could try the same workloads on MACv1 if in doubt, that could hint to a problem.


I see similar errors with MACv1, it's usually because I'm attempting to send more data than the network (or internet connection) can cope with. The error that the application code usually sees is temporary memory shortage when trying to stream messages totalling about 1.8Mb/s, with a nominal 2mb/s uplink speed, but a little slower in reality. I also see a few dropped packets etc. (IP 0.01%, TCP 0.002% approx on my F767 test board) on a local network, with the MQTT broker on a WLAN, even though I've used lwip settings based on that workload.

The difference with the current test is I'm requesting about 2500 bytes via web server and mqtt client about 10 times/second, so a smaller load, but a lot of inbound connects, disconnects and data that I don't normally have. I've got all debug options enabled, and no compiler optimisations, so I'm not too concerned about 0.02% IP and only 1 TCP dropped packets, but it's something I will be checking further - I prefer zero errors.

I will be leaving this running overnight as well, so I'll have more stats in the morning, assuming it keeps going.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Wed Jul 01, 2020 5:51 pm
by mikeprotts
The run failed with an issue that I've seen beforeon the F7, so that's not to do with the MACv2 code.

I sometimes see a thread reference count reach 255, possibly because of running through the list of threads simultaneously from two threads with code that may not be thread safe. I've changed my test and am running again, this time with gdb connected so I can interrogate if there's another problem.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Wed Jul 01, 2020 7:48 pm
by Giovanni
Scanning threads should be thread safe, are you doing it through the shell? if not then I need to see the code.

Giovanni

Re: [DEV] STM32H7xx support (new)

Posted: Wed Jul 01, 2020 9:15 pm
by mikeprotts
It's not through the shell, it's a modified copy of code from the ChibiOS 3 threads shell command. It's included in part of a larger section collecting diagnostics that was definitely not thread safe as it writes to a single static area - I've put a mutex around it now.

My latest test overflowed the lwip thread stack, which was allocated rather low (512) so I've increased it to 1024. Again it's something I have seen on the F7 board, so not MACv2 specific. This is a problem I think is related to turning off all compiler optimisations, which seems to increase stack usage.

I will try a soak test with simpler code, as that will reduce the number of variables - I've only just finished moving from ChibiOS 18 to ChibiOS 20, lwip from 2.0.3 to 2.1.2, stopped using heap, and partially ported my application code from F7 to H7, so there are plenty of potential areas for error.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Thu Jul 02, 2020 10:12 pm
by mikeprotts
The MACv2 soak test is still running after more than 24 hours with continuous requests on the web server. I will leave it running for now.

Mike

Re: [DEV] STM32H7xx support (new)

Posted: Thu Jul 09, 2020 3:54 pm
by geebee
Mike,
thanks for implementing this! I've been running it for the past two days and it's been pretty solid (I haven't done a stress test though). One things I've noticed is that most (all?) of the times I need to power cycle after reprogramming the MCU, with the driver getting stuck here

Code: Select all

366     ETH->DMAMR |= ETH_DMAMR_SWR;
367     while (ETH->DMAMR & ETH_DMAMR_SWR)
368       ;


Now, in the firmware I'm not resetting the PHY on startup so I should look into that at some point, but this board is a straight port from a design based on the F767, with the same PHY and everything else, and there it didn't get stuck on reprogramming in the same conditions. I see in the manual that
The reset operation is complete only when all resets in all active clock domains are
deasserted. Therefore, it is essential that all PHY inputs clocks (applicable for the
selected PHY interface) are present for software reset completion. The time to complete
the software reset operation depends on the frequency of the slowest active clock.

But I'm not so sure why that's any different on reprogramming.

Anyway, not a major issue, I'm definitely in favor of the patch going in.

Another thing I'm wondering about is the "RMII" preprocessor warning. Was that just a leftover from development, or there is something to beware of with RMII, which I'm using?

Thanks,

GB

Re: [DEV] STM32H7xx support (new)

Posted: Thu Jul 09, 2020 4:34 pm
by mikeprotts
Power cycle needed after reprogramming - I will take a look. I suspect something's not been fully initialised so is in the state from when last running. I had a bit of difficulty getting the resets & initialisation order working, so there's probably still something left to do there.

The #warning "RMII" line is in as a reminder to me that the MII code has not been exercised, I don't have any suitable hardware for that. I tend to use #warning where I want to revisit code; I like to see a build with no warnings, so these stand out for me.

There are a couple of TODO comments as well, which are points I wanted to confirm (am I handling the CRC in a safe way, am I always using the correct macp->rdindex value). I'm expecting someone to come up with more bugs, so plan to tidy those up later.

I'm using the Nucleo144 with the STM32H743 Y revision. I'd be interested to know which hardware you're using - including the PHY if it's not a standard board.

Mike