Page 4 of 10
Re: [DEV] STM32H7xx support (new)
Posted: Fri Jun 26, 2020 1:25 pm
by mikeprotts
Giovanni wrote: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
Re: [DEV] STM32H7xx support (new)
Posted: Fri Jun 26, 2020 3:29 pm
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Fri Jun 26, 2020 3:51 pm
by Giovanni
How those settings are different? you need to place your descriptors in SRAM3.
Giovanni
Re: [DEV] STM32H7xx support (new)
Posted: Fri Jun 26, 2020 5:10 pm
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Sat Jun 27, 2020 4:12 pm
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Sat Jun 27, 2020 9:14 pm
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Sun Jun 28, 2020 7:11 am
by Giovanni
It is possible the driver loses sync with the used/filled buffers somehow, MACv1 has a quite complex loop there.
Giovanni
Re: [DEV] STM32H7xx support (new)
Posted: Sun Jun 28, 2020 10:56 am
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Sun Jun 28, 2020 2:19 pm
by 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
Re: [DEV] STM32H7xx support (new)
Posted: Sun Jun 28, 2020 2:28 pm
by Giovanni
You should review the descriptors mechanism, if I remember well MACv1 used an unused bit into a descriptor word for "holding" it.
Giovanni