[DEV] STM32H7xx support (new)

[mikeprotts]

Of course at least some basic functionality is needed.

I can see the transmit buffer is getting sensible looking data and the flags on the descriptors update. I think my problem is the IRQ never firing, which I would expect to happen after mac_lld_release_transmit_descriptor completes (using breakpoints to see what's happening). I don't know if that's the DMA configuration meaning it's not completing a transmit or the IRQ not being initialised correctly.

I guess I need to check the DMA & IRQ registers to check the current state, it's always hard to find out why something isn't happening when it should.

Mike

[mikeprotts]

The STM knowledge article https://community.st.com/s/article/FAQ- ... -STM32H7x3 suggests the following:

Code: Select all

void MPU_Config(void)
{
   MPU_Region_InitTypeDef MPU_InitStruct;

   /* Disables the MPU */
   HAL_MPU_Disable();
   /**Initializes and configures the Region and the memory to be protected 
   */
   MPU_InitStruct.Enable = MPU_REGION_ENABLE;
   MPU_InitStruct.Number = MPU_REGION_NUMBER2;
   MPU_InitStruct.BaseAddress = 0x30040000;
   MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
   MPU_InitStruct.SubRegionDisable = 0x0;
   MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
   MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
   MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
   MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
   MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
   MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;

   HAL_MPU_ConfigRegion(&MPU_InitStruct);

   /**Initializes and configures the Region and the memory to be protected 
   */
   MPU_InitStruct.Enable = MPU_REGION_ENABLE;
   MPU_InitStruct.Number = MPU_REGION_NUMBER1;
   MPU_InitStruct.BaseAddress = 0x30044000;
   MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
   MPU_InitStruct.SubRegionDisable = 0x0;
   MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
   MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
   MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
   MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
   MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
   MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

   HAL_MPU_ConfigRegion(&MPU_InitStruct);

   MPU_InitStruct.Enable = MPU_REGION_ENABLE;
   MPU_InitStruct.Number = MPU_REGION_NUMBER0;
   MPU_InitStruct.BaseAddress = 0x30040000;
   MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
   MPU_InitStruct.SubRegionDisable = 0x0;
   MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
   MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
   MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
   MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
   MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
   MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
   
   HAL_MPU_ConfigRegion(&MPU_InitStruct);

   /* Enables the MPU */
   HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}

The hal_ld.c file has:

Code: Select all

  /* MPU initialization.*/
#if (STM32_NOCACHE_SRAM1_SRAM2 == TRUE) || (STM32_NOCACHE_SRAM3 == TRUE)
  {
    uint32_t base, size;

#if (STM32_NOCACHE_SRAM1_SRAM2 == TRUE) && (STM32_NOCACHE_SRAM3 == TRUE)
    base = 0x30000000U;
    size = MPU_RASR_SIZE_512K;
#elif (STM32_NOCACHE_SRAM1_SRAM2 == TRUE) && (STM32_NOCACHE_SRAM3 == FALSE)
    base = 0x30000000U;
    size = MPU_RASR_SIZE_256K;
#elif (STM32_NOCACHE_SRAM1_SRAM2 == FALSE) && (STM32_NOCACHE_SRAM3 == TRUE)
    base = 0x30040000U;
    size = MPU_RASR_SIZE_16K;
#else
#error "invalid constants used in mcuconf.h"
#endif

    /* The SRAM2 bank can optionally made a non cache-able area for use by
       DMA engines.*/
    mpuConfigureRegion(STM32_NOCACHE_MPU_REGION,
                       base,
                       MPU_RASR_ATTR_AP_RW_RW |
                       MPU_RASR_ATTR_NON_CACHEABLE |
                       size |
                       MPU_RASR_ENABLE);
    mpuEnable(MPU_CTRL_PRIVDEFENA);

    /* Invalidating data cache to make sure that the MPU settings are taken
       immediately.*/
    SCB_CleanInvalidateDCache();
  }
#endif
}

The settings I've been using:

Code: Select all

/*
 * Memory attributes settings.
 */
#define STM32_NOCACHE_MPU_REGION            MPU_REGION_6
#define STM32_NOCACHE_SRAM1_SRAM2           FALSE
#define STM32_NOCACHE_SRAM3                 TRUE

I've tried with #define STM32_NOCACHE_SRAM1_SRAM2 TRUE as well.

I think I need to rework hal_lld.c to allow the setting suggested by STM, but I'm concerned this will have rather far reaching consequences. Is this something that would be better reconfigured within the hal_mac_lld.c code?

Mike

[Giovanni]

How those settings are different? you need to place your descriptors in SRAM3.

Giovanni

[mikeprotts]

I'm using SRAM3 for the buffers and descriptors, but the STM doc is suggesting descriptors, RX and TX buffers each have different settings

The part I'm not sure about is described in the STM doc:
256 bytes at 0x30040000 configured as Shared Device, MPU region 2 (required for overlapping)
This is for RX and TX DMA descriptors

And that's configured overlapping SRAM3, but marked as MPU_ACCESS_BUFFERABLE and MPU_TEX_LEVEL0.

It also states:

Code: Select all

TX and RX DMA descriptors (defined in ethernetif.c file) should be located in D2 SRAM and be configured by MPU as Device memory or Strongly-ordered type.

and

Code: Select all

RX buffer (defined in ethernetif.c file) should be located in D2 SRAM and must not be configured as Device memory type (because IP stacks like LwIP can access the received data unaligned).
This is also set by default by CubeMX for Keil and IAR IDEs. Again For GCC, you need to modify the linkerscript (please see the examples)
Shouldn't be placed in MPU region of TX and RX DMA descriptors
Should be configured as non-cacheable memory, or write-through

which suggests the RX side can have problems.

I'll read up a bit more on these memory options, I need to understand the implications better.

Mike

[mikeprotts]

While putting in more diagnostics I've found that a reset of DMAMR resets the MAC address as well. It has to be after the PHY has been put into power up mode or it never completes the reset.

Progress, now I see one transmit, two interrupts and one receive.

Mike

[mikeprotts]

64 bytes from 192.168.13.73: icmp_seq=9 ttl=255 time=122 ms

Only manages a few, but a ping response means it's receiving and transmitting. I think the looping isn't working yet, so it stops when it's used all the buffers in the ring.

Mike

[Giovanni]

It is possible the driver loses sync with the used/filled buffers somehow, MACv1 has a quite complex loop there.

Giovanni

[mikeprotts]

The problem with buffer ring was assuming Ring Length meant length (1 to N), it seems to be index (0 to N-1) - something I'd changed since the last code was uploaded. Now it's responding to pings intermittently, but that's something I can work on. I suspect it's to do with when I enable the interrupts.

Code: Select all

ping 192.168.13.73
PING 192.168.13.73 (192.168.13.73) 56(84) bytes of data.
64 bytes from 192.168.13.73: icmp_seq=9 ttl=255 time=2818 ms
64 bytes from 192.168.13.73: icmp_seq=10 ttl=255 time=1778 ms
64 bytes from 192.168.13.73: icmp_seq=11 ttl=255 time=738 ms
64 bytes from 192.168.13.73: icmp_seq=14 ttl=255 time=1040 ms
64 bytes from 192.168.13.73: icmp_seq=15 ttl=255 time=0.741 ms
^C
--- 192.168.13.73 ping statistics ---
15 packets transmitted, 5 received, 66% packet loss, time 14630ms
rtt min/avg/max/mdev = 0.741/1275.414/2818.487/959.402 ms, pipe 3

It seems there's probably more a transmit problem now, based on the stats from lwip:

Code: Select all

>LINK   xmit: 158       recv: 1372      fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 0
>ETHARP         xmit: 33        recv: 1200      fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 98
>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: 134       recv: 172       fw: 0   drop: 49        chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 49     opterr: 0       err: 0  cachehit: 0
>ICMP   xmit: 110       recv: 110       fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 0
>TCP    xmit: 24        recv: 13        fw: 0   drop: 0         chkerr: 0       lenerr: 0       memerr: 0       rterr: 0        proterr: 0      opterr: 0       err: 0  cachehit: 13

The ICMP suggests all pings answered, and TCP would be web page requests. So I'll try to find time to work out why the transmits don't complete or generate errors. It's possible I'm reusing descriptors before they get a chance to transmit, in which case I may need to implement a lock similar to the MACv1 STM32_TDES0_LOCKED flag.

Mike

[mikeprotts]

Ping output has some very delayed duplicate responses and errors:

Code: Select all

64 bytes from 192.168.13.73: icmp_seq=2231 ttl=255 time=0.669 ms
64 bytes from 192.168.13.73: icmp_seq=2180 ttl=255 time=58240 ms (DUP!)
wrong data byte #22 should be 0x16 but was 0x38
#8      8 9 a b c d e f 10 11 12 13 14 15 38 37 36 35 38 37 36 35 38 37 36 35 38 37 36 35 38 37 
#40     36 35 38 37 36 35 38 37 36 35 38 37 36 35 36 37 
64 bytes from 192.168.13.73: icmp_seq=2237 ttl=255 time=4198 ms
64 bytes from 192.168.13.73: icmp_seq=2238 ttl=255 time=3120 ms
64 bytes from 192.168.13.73: icmp_seq=2239 ttl=255 time=2080 ms
64 bytes from 192.168.13.73: icmp_seq=2180 ttl=255 time=68640 ms (DUP!)
wrong data byte #22 should be 0x16 but was 0x38
#8      8 9 a b c d e f 10 11 12 13 14 15 38 37 36 35 38 37 36 35 38 37 36 35 38 37 36 35 38 37 
#40     36 35 38 37 36 35 38 37 36 35 38 37 36 35 36 37 
64 bytes from 192.168.13.73: icmp_seq=2245 ttl=255 time=1040 ms

The error lines show a telltale pattern, which means an uninitialised transmit buffer is being used. This suggests it's sending buffers based on wrong pointer, and not clearing them.

The web server running in the board responds very slowly ( 6 seconds to minutes), but returns good data.

However, it's on the network and half working, so some useful progress.

Mike

[Giovanni]

You should review the descriptors mechanism, if I remember well MACv1 used an unused bit into a descriptor word for "holding" it.

Giovanni