2019-05-20 03:37 PM
Dear Members,
I have an own board with STM32H753ZIT as MCU and I am trying to get ETH working.
Unfortunately, I have a DP83848 PHY on this board which worked perfectly well using an STM32F407VIT earlier (DP83848 is intact in the schematic but connected to the new MCU representative PINs).
However, in the current firmware of STM32H7, the PHY handling code is completely rewritten and it relies on some of the special features of LAN8742A.
At my side, I have modified the code to be able to use it with my DP83848, so it finds PHY address, senses cable connection / reconnection, speed, half/full duplex mode, etc... so at management side it should be okay.
(Anyway, ST would have been written the code to be a bit more flexible to use PHY other than LAN8742 which is not very well solderable by hand.)
ETH LEDs are also working as they should - one is lights up on cable connection and the other lights up when data arrives from the network.
On connecting a LAN cable, LWIP starts sending DHCP requests (and calls low_level_output function in ethernetif.c), but HAL_ETH_IsRxDataAvailable in low_level_input function is never true and nothing arrives.
I have looked at appropriate PINs using an oscilloscope and I can not see any communications at TXD0 and TXD1, not even at TX_EN, so MCU does not send anything to PHY on these lines.
At RXD0 and RXD1, I can see communication, so PHY sends packages coming from the network towards MCU.
PHY is connected by RMII interface using the same schematic at DP83848 side what I used together with STM32F4 series MCU with a 50 MHz active crystal (which is also working).
So it seems there are some configuration issues which lead to communication failure at MCU side.
Code was generated by STM32CubeMX and compiled using GCC from AC6 System Workbench on Linux. These systems are up-to-date.
So, does STM32H7 really has working ETH solution using RMII interface generated by STM32CubeMX or may have some issues at HAL side?
Also, I don't really understand what the following notice means in STM32CubeMX:
"The ETH can work only when RAM is pointing at 0x24000000"
I have set "First RX / TX Descriptor Address" and "RX Buffers Address" in this range, but I don't really see what I should set in order to have a right configuration.
What is this notice really mean and what should I do to get Ethernet working on this chip?
Does anyone have any suggestions?
Thank you your help in advance.
2019-05-20 11:01 PM
Well, I doubt anybody will jump in with a magic solution, so I guess you are at your own.
You may want to start with checking whether all three clock enables are set in RCC, and if SYSCFG_PMCR.EPIS is set to RMII. Then try to compare the register settings in ETH with those in 'F4xx - there may be differences between these modules but I'd say the key registers will be similar. Finally, find out whether the Tx buffers are set up properly and check the Tx DMA governing registers, including the channel status register.
JW
2019-05-22 05:55 PM
Thank you your reply.
I have looked at H7 example applications part, which had some explanations in readme.txt
The main problem was that "The internal DMA of the Ethernet peripheral can't access the DTCM memory (@0x20000000) of the STM32H7, All data accessible by the Ethernet DMA must be located in the D1 or D2 SRAM."
So, STM32H753ZITx_FLASH.ld had to be modified to use RAM_D1 instead of DTCM memory.
I have also set MPU unit according to the application example.
That way I could see by an oscilloscope that the MCU has started sending packages on TXD0 / TXD1 lines and TX_EN line was also worked.
Additionally, incoming data has appeared in low_level_input function (HAL_ETH_IsRxDataAvailable was true) and some data are arrived.
However, network communication still not worked.
To get it working, it was needed to invalidate data cache near DMA process by calling SCB_CleanInvalidateDCache(); in this case at low_level_input and low_level_output functions like what I have found in the application example.
After these modifications, it seems Ethernet was started working.
Currently it gets an IP address from DHCP and responds to PING requests.
2019-09-09 02:10 AM
@VaZso Hi, I made ethernet communication with LAN8742A on stm32h7. But this now I need to use DP83848. Can you share ethernetif.c driver file to me? Thank youu for your help.
2019-09-09 04:12 AM
Hi,
I have attached these .c and .h files (ethernetif & dp83848) to this comment.
Pleas keep in mind that these files were used to get DP83848 up and working while STM32CubeMX is also able to update its code.
My dp83848.h and dp83848.c files are completely based on the appropriate lan8742 files, but register address / values were modified where it was needed.
Also, I had to 'cheat' a bit to be able to modify ethernet_link_check_state function which is autogenerated by STM32CubeMX, thus, it would revert to lan8742 otherwise. So, this function is replaced independently of what STM32CubeMX do with the original function, however, if it was modified since May, it may have to be adapted again...
I have not updated CubeMX code to actual version as I have decided to wait till STM32H7 will be more popular/stable.
I have removed the portion where MAC address was set and translated some comments inside.
It worked well for me but I have not used it extensively.
Again, I don't know what have been changed in code base in last months, it is currently in the same state when the topic was opened.
Anyway, I hope it helps and I also hope ST will give us an option for easier use of any other PHYs as this 'cheat' is not the best solution...
(Maybe there are another options for that in generator, I don't exactly know what is there now.)
2019-09-09 09:26 AM
@VaZso Hi, I use STM32H750VB and my ETH part trouble is similar to you ,and could you please tell me what's the the STM32H753ZITx_FLASH.ld means as to --"So, STM32H753ZITx_FLASH.ld had to be modified to use RAM_D1 instead of DTCM memory."? Is that DMARxDscrTab/DMATxDscrTab/Rx_Buff address? Thank you for your reply.
2019-09-09 10:02 AM
Practically, I put almost everything to RAM_D1 like in the example project was.
I mean the following way:
/* Initialized data sections goes into RAM, load LMA copy after code */
.data :
{
. = ALIGN(4);
_sdata = .; /* create a global symbol at data start */
*(.data) /* .data sections */
*(.data*) /* .data* sections */
. = ALIGN(4);
_edata = .; /* define a global symbol at data end */
} >RAM_D1 AT> FLASH
/* Uninitialized data section */
. = ALIGN(4);
.bss :
{
/* This is used by the startup in order to initialize the .bss secion */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >RAM_D1
/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
. = ALIGN(8);
PROVIDE ( end = . );
PROVIDE ( _end = . );
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
. = ALIGN(8);
} >RAM_D1
...so using memory address defined in RAM_D1 instead of DCMRAM
Anyway, memories used by the DMA controller should be defined in an area which it has access to.
2019-09-09 07:11 PM
@VaZso Thank you! My problem is soloved, and i put everything of "+RW,+ZI" to D1, but this still didn't work, Then i turn off the cache, ETH is worked, So i should look into this part of cache how its works... hope be helpfull for other guys.
2019-09-09 07:36 PM
As to my project (STM32H750VB + RMII), should corrent it like this:
2019-09-09 10:05 PM
thank you dear friends. @VaZso