I've also tested as an MQTT client connecting to a local broker, seems fine so far. lwip stats not showing any errors.
Mike
[DEV] STM32H7xx support (new)
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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.
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32H7xx support (new)
You could try the same workloads on MACv1 if in doubt, that could hint to a problem.
Giovanni
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32H7xx support (new)
Scanning threads should be thread safe, are you doing it through the shell? if not then I need to see the code.
Giovanni
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
Mike
Re: [DEV] STM32H7xx support (new)
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
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
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
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
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 46 guests