I have seen the issues with DMA and the STM32H7 (here: https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3), and I believe that I have implemented everything that was written there. To place all my variables into D1 SRAM, I replaced my linker script file with one from the STM32H7 demo programs (and I see in the debugger all data are at 0x24xxxxxx). I enabled the MPU and set it up like in the example in the FAQ, and see that STM32CubeMX did, in fact map the Tx/Rx Descriptors and buffers to the MPU regions as in the example.
I have a double issue with the way the PHY is implemented: I am using, for historical reasons, a TI TLK105L PHY on this project, rather than the LAN8742 that STM32CubeMX supports. The first issue is that, although ST claims that you can select either LAN8742 or User Defined PHY, what it really means is you can select LAN8742 or leave the selection of PHY at "choose", then ignore the warning message and allow it to generate code which doesn't have any PHY code at all. So I generated code for the LAN8742, and began to debug it. The first issue was where the LAN8742 figures out its own internal address (0-31) by trial and error, using an extended register which is different from that of the TI part. I replaced the code there with a fixed address (mine is set by the strapping pins, and I don't need to modify it in software). I then proceeded to read the ID registers as a check to make sure the CPUs MACC is speaking with the PHY, and it is.
However, there is still a bit of code in the file LAN8742.c which won't work correctly - although I didn't bother modifying it, because the Cube-generated code doesn't call it. The only functions called there are LAN8742_RegisterBusIO (which doesn't actually touch the hardware, and isn't a problem), and LAN8742_Init (which the only problem I had was the one mentioned earlier). Nowhere is the code calling functions such as get/set Link Status, etc. For now I left it alone.
I now am trying to find what I have to fix - I have to fix something, as nothing is working. I am running FreeRTOS, with the EthIF task blocking after HAL_ETH_GetRxDataBuffer returns with an error (no data available), the tcpip_thread blocking on a mailbox, the Timer service blocking on empty timer lists, and my default task which is doing a bunch of stuff and resting and the idle task sharing the CPU.
I tried to shorten the very long semaphore wait in the loop around low_level_input, by changing it from TIME_WAITING_FOR_INPUT (which was portMAX_DELAY) to 1000, but it doesn't seem to be getting back to low_level_input a second time, which leads me to believe I'm missing something in the mapping which is making the DMA idle, or something to that effect.
There is the remote possibility that this is a hardware issue, but I doubt it (the board is new and we are shaking out the bugs), but as I know there is so much room for SW issues, I'm betting on it. In any case, that's my part of the job.
Has anyone else had to deal with either of these issues - either the Etherne DMA mapping issue, or the Cube generated ethernetif.c code for a different PHY? Any help will be greatly appreciated.
