[DEV] STM32H7xx support (new)

[mikeprotts]

I don't see any problem with reloading firmware, but there are potentially a few differences.

I have this fix on my source tree added yesterday (on top of the 20 stable code):
https://osdn.net/projects/chibios/scm/svn/commits/13724

I've configured:

#define CH_CFG_USE_HEAP FALSE

and I'm working with lwip 2.1.7 with my suggested change to use memory pools.

These are the MAC & ETH settings I'm using (note that docs suggest I should have multiples of 4 for STM32_MAC_TRANSMIT_BUFFERS and STM32_MAC_BUFFERS_SIZE):

Code: Select all

grep MAC *
halconf.h: * @brief   Enables the MAC subsystem.
halconf.h:#if !defined(HAL_USE_MAC) || defined(__DOXYGEN__)
halconf.h:#define HAL_USE_MAC                         TRUE
halconf.h:/* MAC driver related settings.                                              */
halconf.h:#if !defined(MAC_USE_ZERO_COPY) || defined(__DOXYGEN__)
halconf.h:#define MAC_USE_ZERO_COPY                   FALSE
halconf.h:#if !defined(MAC_USE_EVENTS) || defined(__DOXYGEN__)
halconf.h:#define MAC_USE_EVENTS                      TRUE
mcuconf.h: * MAC driver system settings.
mcuconf.h:#define STM32_MAC_TRANSMIT_BUFFERS          2
mcuconf.h:#define STM32_MAC_RECEIVE_BUFFERS           4
mcuconf.h:#define STM32_MAC_BUFFERS_SIZE              1522
mcuconf.h:#define STM32_MAC_PHY_TIMEOUT               100
mcuconf.h:#define STM32_MAC_ETH1_CHANGE_PHY_STATE     TRUE
mcuconf.h:#define STM32_MAC_ETH1_IRQ_PRIORITY         13
mcuconf.h:#define STM32_MAC_IP_CHECKSUM_OFFLOAD       0

grep ETH *
mcuconf.h:#define STM32_MAC_ETH1_CHANGE_PHY_STATE     TRUE
mcuconf.h:#define STM32_MAC_ETH1_IRQ_PRIORITY         13


Mike

[geebee]

My suspicion is that the ETH block is left in some state that does not play well with re-initializing. It seems to happen only when the Ethernet cable is in and the link is up. Anyway, don't worry too much about it, I will look a bit more today and try to figure out what's happening.

The board is a custom board pretty similar to the Nucleo board for the relevant parts:
- STM32H743VIT6 Rev V
- 8742A PHY (RMII)
- main difference is probably that I'm using a BlackMagic programmer instead of st-link

I'll update the thread if I figure out anything.

GB

[mikeprotts]

The programmer may make a difference, I usually use swd from a raspberry Pi for loading, but the st-link is convenient at this stage.

It could be related to the later revision, although I can't see anything in the errata to suggest anything related behaves differently.

Mike

[geebee]

It seems that resetting the PHY via the reset pin before lwipInit() does the trick, so as far as I'm concerned everything looks good. Not sure why it used to work without it on the F767. I'll let you know if I bump into anything else, but so far it's looking very good. Thanks!

[mikeprotts]

It seems that resetting the PHY via the reset pin before lwipInit() does the trick, so as far as I'm concerned everything looks good. Not sure why it used to work without it on the F767. I'll let you know if I bump into anything else, but so far it's looking very good. Thanks!

Is resetting the PHY something that should be done differently around line 279 in hal_mac_lld.c:

Code: Select all

#if defined(BOARD_PHY_RESET)
  /* PHY board-specific reset procedure.*/
  BOARD_PHY_RESET();
#else
  /* PHY soft reset procedure.*/
  mii_write(&ETHD1, MII_BMCR, BMCR_RESET);
#if defined(BOARD_PHY_RESET_DELAY)
  osalSysPolledDelayX(BOARD_PHY_RESET_DELAY);
#endif


It may be worth experimenting with the delay (this is where I'd use #warning messages to check the build path).

Is it possible I'm doing a bit more with the openocd command I use:

Code: Select all

~/openocd/bin/openocd -f interface/stlink.cfg -c "set WORKAREASIZE 0x2000" -f target/stm32h7x.cfg -c "program build/ch.elf verify reset" -c "shutdown"

or more usually this is the script for the F767 programmed using Raspberry Pi GPIO pins:

Code: Select all

source [find interface/raspberrypi2-native.cfg]
transport select swd
set BSTAPID 0x06413041
source [find target/stm32f7x.cfg]
reset_config none separate
adapter_nsrst_delay 500
adapter_nsrst_assert_width 500
adapter_khz 250
init
targets
reset
halt
sleep 1250
set WORKAREASIZE 0x2000
program build/ch.elf verify reset
shutdown


Too many variables ...

Mike

[mikeprotts]

As part of tidying code, what is the preferred style for removing CRC:

Currently I've coded in mac_lld_get_receive_descriptor():
hal_mac_lld.c:

Code: Select all

      rdp->size     = (rdes->rdes3 & STM32_RDES3_PL_MASK) -2; /* Lose CRC TODO check */


based on the docs saying:
These bits indicate the byte length of the received packet that was
transferred to system memory (including CRC).

So that removes the CRC, and it seems to be correct, so I'll remove the TODO comment. But would it be preferred as:
a)
hal_mac_lld.c

Code: Select all

      rdp->size     = (rdes->rdes3 & STM32_RDES3_PL_MASK) -2;  /* Lose CRC */


b)
hal_mac_lld.c

Code: Select all

      rdp->size     = rdes->rdes3 & STM32_RDES3_PL_MASK & ~3UL;  /* Lose CRC */


c)
hal_mac_lld.c

Code: Select all

      rdp->size     = rdes->rdes3 & STM32_RDES3_PL_MASK & ~0x00000003;  /* Lose CRC */


d)
hal_mac_lld.h

Code: Select all

#define STM32_RDES3_CRC_MASK 0x00000003


hal_mac_lld.c

Code: Select all

      rdp->size     = rdes->rdes3 & STM32_RDES3_PL_MASK & ~STM32_RDES3_CRC_MASK;


I think d) would be clearer


For comparison, the MACv1 mac_lld_get_receive_descriptor() code has:

Code: Select all

rdp->size     = ((rdes->rdes0 & STM32_RDES0_FL_MASK) >> 16) - 4;


The docs say:
These bits indicate the byte length of the received frame that was transferred to host memory (including CRC).

So I don't know how the value of 4 was chosen.


Mike

[mikeprotts]

Looking back, I don't think those are equivalent, so option a) would be the one.

However I'd still be interested to know where the -4 came from for MACv1.

Mike

[Giovanni]

I don't remember why that -4, removing some information appended to the frame maybe.

Giovanni

[mikeprotts]

As I'm tidying to try to minimise the size of patch and remove any junk (without making any functional changes):

1) At the moment I think MACv2 is for STM32H7XX only, so I will to remove any code that's not relevant to this processor family and #error if STM32H7XX is not defined. If there's another processor type that can use it in future it can be added.

2) There is MACv1 code for MAC_USE_ZERO_COPY (mac_lld_get_next_transmit_buffer and mac_lld_get_next_receive_buffer) that I've not converted to MACv2 as I've not used it. For now I think I should #error this section as not currently supported, and remove the MACv1 code, unless someone can suggest it's easy to implement and test. I don't want to delay the fix for something that may not be needed, unless it doesn't take too long.

3) The small patches to the relevant STM32H7XX/platform.mk and STM32H7XX/stm32_rcc.h files probably belong with the patch for the new MACv2/* files, but I can split as separate patch or patches if preferred.

4) The specific board file (ST_NUCLEO144_H743ZI/board,h) is probably best as a separate patch, as it should probably be regenerated but I've never looked at the board.chcfg file. I can take a look at this later.

5) Are there preferred diff options for the patch, or is if fine to attach the full files (zip or tgz) as before?

Mike

[twarge]

I'd like to cast a vote in favor of mikeprotts' new H7 MAC driver. It's been running well for several days now on my board.

Giovanni, can you please pull this into the next point release?