Hi,
Opening this topic about the restarted development of the STM32H7xx platform.
In trunk there are a series of new things:
- Support for 480MHz devices.
- Fixes in driver caused by changes in REV-Y devices.
- Compatibility mode for old REV-V devices (400MHz).
- Support for dual core STM32H7 devices. The HAL has an M7 mode and an M4 mode, M4 is not tested yet (anybody able to debug it using OpenOCD?).
- New QUADSPIv2 driver.
- New SDMMCv2 driver.
- STM32H755ZI-Nucleo144 demo in M7 mode.
In addition, I modified the SPI test application to run to much higher speeds and perform different-length exchanges, so far I saw no anomaly...
Giovanni
[DEV] STM32H7xx support (new)
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14455
- 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)
Some impressive benchmarks (480MHz):
Giovanni
Code: Select all
*** ChibiOS/RT Test Suite
***
*** Compiled: Feb 8 2020 - 12:46:21
*** Platform: STM32H755 Dual Core Very High Performance with DSP and FPU
*** Test Board: STMicroelectronics STM32 Nucleo144-H755ZI
***
*** Text size: 41728 bytes
*** RO data size: 10668 bytes
*** Data size: 220 bytes
*** BSS size: 7744 bytes
============================================================================
=== Test Sequence 11 (Benchmarks)
----------------------------------------------------------------------------
--- Test Case 11.1 (Messages performance #1)
--- Score : 2222193 msgs/S, 4444386 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.2 (Messages performance #2)
--- Score : 1846127 msgs/S, 3692254 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.3 (Messages performance #3)
--- Score : 1846125 msgs/S, 3692250 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.4 (Context Switch performance)
--- Score : 7164072 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.5 (Threads performance, full cycle)
--- Score : 1290219 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.6 (Threads performance, create/exit only)
--- Score : 1579359 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.7 (Mass reschedule performance)
--- Score : 604527 reschedules/S, 3627162 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.8 (Round-Robin voluntary reschedule)
--- Score : 4804740 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.9 (Virtual Timers set/reset performance)
--- Score : 3422722 timers/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.10 (Semaphores wait/signal performance)
--- Score : 8135472 wait+signal/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.11 (Mutexes lock/unlock performance)
--- Score : 6575240 lock+unlock/S
--- Result: SUCCESS
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:M4 is not tested yet (anybody able to debug it using OpenOCD?).
I've got the standard demo (RT-STM32H743ZI_REV_V-NUCLEO144) running using OpenOCD and debugging with GDB. What would be needed to test M4 mode? Is it just a case of changing MCU to cortex-m4 in Makefile, or would I need to also need to use different startup, platform and build mk files?
Mike
- Giovanni
- Site Admin
- Posts: 14455
- 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)
Hi,
That demo is not for the dual core version, it is for the OLD revision of H743 (the one limited to 400MHz). You should start from the H755 demo.
The H755 has a new setting in mcuconf.h:
You can use it for the M7 side or for the M4 side, it is still untested on the M4 however, it is not clear to me how to debug the M4 instead of the M7 using OpenOCD.
Giovanni
That demo is not for the dual core version, it is for the OLD revision of H743 (the one limited to 400MHz). You should start from the H755 demo.
The H755 has a new setting in mcuconf.h:
Code: Select all
/**
* @brief Target code for this HAL configuration.
* @note Core 1 is the Cortex-M7, core 2 is the Cortex-M4.
*/
#if !defined(STM32_TARGET_CORE) || defined(__DOXYGEN__)
#define STM32_TARGET_CORE 1
#endif
You can use it for the M7 side or for the M4 side, it is still untested on the M4 however, it is not clear to me how to debug the M4 instead of the M7 using OpenOCD.
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
At the moment I've only got the H743 - I'll try to source a dual core dev board to see what's possible. In the mean time I'll see if I can try the MAC driver.
Mike
Mike
- Giovanni
- Site Admin
- Posts: 14455
- 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)
Hi,
The current MAC driver cannot work on H7, there is a new IP in this device and it is not yet supported. A new MACv2 will be required I think, I have not yet really looked into it but it is possible that it is quite similar to the old one.
Giovanni
The current MAC driver cannot work on H7, there is a new IP in this device and it is not yet supported. A new MACv2 will be required I think, I have not yet really looked into it but it is possible that it is quite similar to the old one.
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
The ETH_TypeDef struct is very different from the F767 I've been using, it'll take me a while to work out how much is in common. I'll start with a simple copy of MACv1 and see what's broken.
Mike
Mike
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
I've got a MACv2 version to compile, but of course that's a long way off actually working .
I think I've been able to match the register names correctly, but there are a couple of places where there seems to be less compatible changes. That's likely to trip me up.
Mike
I think I've been able to match the register names correctly, but there are a couple of places where there seems to be less compatible changes. That's likely to trip me up.
Mike
- Giovanni
- Site Admin
- Posts: 14455
- 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)
The working model is the same, it seems to be a more recent version of the same Synopsys IP.
Hopefully it will work with just some registers/constants renaming.
Giovanni
Hopefully it will work with just some registers/constants renaming.
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
I've made limited progress, not working yet, but just want to keep things on track.
I've created a MACv2 clone from MACv1 (see attached).
To use this (new <, old >):
A minor change to as ETH seems to be ETH1:
Now the current state it loads but fails to find the PHY:
The suspect code:
And the suspect line (because I changed it):
I think MACMDIODR is the correct replacement for MACMIIDR, so I need to work back to see what's wrong earlier.
I've created a MACv2 clone from MACv1 (see attached).
To use this (new <, old >):
ChibiOS_20.3.1/os/hal/ports/STM32/STM32H7xx/platform.mk
37d36
< include $(CHIBIOS)/os/hal/ports/STM32/LLD/MACv2/driver.mk
A minor change to as ETH seems to be ETH1:
ChibiOS_20.3.1/os/hal/ports/STM32/STM32H7xx/stm32_rcc.h
697,699c697,699
< #define rccEnableETH(lp) rccEnableAHB1(RCC_AHB1ENR_ETH1MACEN | \
< RCC_AHB1ENR_ETH1TXEN | \
< RCC_AHB1ENR_ETH1RXEN, lp)
---
> #define rccEnableETH(lp) rccEnableAHB1(RCC_AHB1ENR_ETHMACEN | \
> RCC_AHB1ENR_ETHMACTXEN | \
> RCC_AHB1ENR_ETHMACRXEN, lp)
706,708c706,708
< #define rccDisableETH() rccDisableAHB1(RCC_AHB1ENR_ETH1MACEN | \
< RCC_AHB1ENR_ETH1TXEN | \
< RCC_AHB1ENR_ETH1RXEN)
---
> #define rccDisableETH() rccDisableAHB1(RCC_AHB1ENR_ETHMACEN | \
> RCC_AHB1ENR_ETHMACTXEN | \
> RCC_AHB1ENR_ETHMACRXEN)
715c715
< #define rccResetETH() rccResetAHB1(RCC_AHB1RSTR_ETH1MACRST)
---
> #define rccResetETH() rccResetAHB1(RCC_AHB1RSTR_ETHMACRST)
Now the current state it loads but fails to find the PHY:
#0 0x08001e00 in chSysHalt (reason=0x801d04c "MAC failure")
at ../ChibiOS_20.3.1/os/rt/src/chsys.c:198
#1 0x08015288 in osalSysHalt () at ../ChibiOS_20.3.1/os/hal/osal/rt-nil/osal.h:480
#2 mii_find_phy.isra.0 ()
at ../ChibiOS_20.3.1/os/hal/ports/STM32/LLD/MACv2/hal_mac_lld.c:159
#3 mac_lld_init ()
at ../ChibiOS_20.3.1/os/hal/ports/STM32/LLD/MACv2/hal_mac_lld.c:282
#4 macInit () at ../ChibiOS_20.3.1/os/hal/src/hal_mac.c:66
#5 halInit () at ../ChibiOS_20.3.1/os/hal/src/hal.c:99
#6 main () at ../teat/test.c:773
The suspect code:
#if !defined(BOARD_PHY_ADDRESS)
/**
* @brief PHY address detection.
*
* @param[in] macp pointer to the @p MACDriver object
*/
static void mii_find_phy(MACDriver *macp) {
uint32_t i;
#if STM32_MAC_PHY_TIMEOUT > 0
unsigned n = STM32_MAC_PHY_TIMEOUT;
do {
#endif
for (i = 0U; i <= 31U; i++) {
macp->phyaddr = i << 11U;
ETH->MACMDIODR = (i << 6U) | MACMDIODR_CR;
if ((mii_read(macp, MII_PHYSID1) == (BOARD_PHY_ID >> 16U)) &&
((mii_read(macp, MII_PHYSID2) & 0xFFF0U) == (BOARD_PHY_ID & 0xFFF0U))) {
return;
}
}
#if STM32_MAC_PHY_TIMEOUT > 0
n--;
} while (n > 0U);
#endif
/* Wrong or defective board.*/
osalSysHalt("MAC failure");
}
#endif
And the suspect line (because I changed it):
148c148
< ETH->MACMDIODR = (i << 6U) | MACMDIODR_CR;
---
> ETH->MACMIIDR = (i << 6U) | MACMIIDR_CR;
I think MACMDIODR is the correct replacement for MACMIIDR, so I need to work back to see what's wrong earlier.
- Attachments
-
- MACv2.tgz
- (7.86 KiB) Downloaded 224 times
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 39 guests