STM32H755 | lwIP | Ping two boards together

[Zzaaack]

Hello everyone,

I open a new topic since my issue seems to be characterizing only my application.

I have implemented what I consider a rather stable lwIP - ModbusTCP/IP on a proprietary application using STM32H755 microcontroller. As long as I work with one board only, everything works fine, both ping and data exchange. As soon as I connect a second identical board but with different IP (verified), only one of the two allows to ping or exchange data(tried to do it together, separately, everything i could think of). If I stop the connection to the first CPU, even disconnecting it's cable, the communication returns to the previous working condition (ok). Then I tried to ping the two CPUs with two different laptops simultanously and the same thing happens, ping works only on one board at a time.

If I try to ping the same board while transferring data (SW too emulating Modbus Client) it works just fine.

To me it seems like a very long handshake, like the link is never left idle for the other participants to complete their operations. I must say that I never even tried to establish multiple connections at once with a laptop to different devices so I didn't think any of it at first and I'm still not sure if it's normal or not, even if I would say not.

Have you ever encountered the same issue while developing on stm32 platforms? Do yuou know any additional test I might perform to address this issue? Or maybe in which direction to look at for more insights? Could it be an issue in my Modbus TCP/IP protocol (just so you know, it's OS free and running it's main functions through callbacks)?

Thank you all in advance,

Zack

[Zzaaack]

@ all

I just went through a self-brainstorming and though about the fact that actually there is one thing that might cause issues on the matter: that is MAC address. CubeMX assigns always the same one to every device.

Tomorrow is testing day, I'll post if it has solved the issue reported.

[Pavel A.]

We use something like this to auto-generate MAC addresses for quick testing.

#include <stm32h7xx_hal.h>

// Generate MAC address from STM32 "unique ID":
// byte [1]=02 (locally managed), [1]=arg, [2..5] from "unique ID"[0]
void BSP_get_MAC_addr(uint8_t addr[6], uint8_t a1)
{
    addr[0] = 0x02;
    addr[1] = a1;
    uint32_t u = HAL_GetUIDw0();
    __UNALIGNED_UINT32_WRITE(&addr[2], u);
}

[Zzaaack]

Yes, the issue was the MAC address as expected.

Unfortunately the solution provided by @Pavel A. is not working in my case since ICache is enabled and I should set MPUs. I must dedicate some more time to the topic, I don't have the required knowledge to proceed in that direction. I'll just use a parameter coming from EE to set it for the time being.

Thanks for the help!

[Piranha]

The device ID has many bits that are likely to be the same for a devices of the same batch. It is much better to compute a 32-bit CRC on all 96 bits of the device ID and use those 4 bytes for the MAC address.

[LCE]

For now (still in dev stage) I'm doing it almost like @Pavel A. :

/* MAC adress: get some bytes from unique STM32 ID at UID_BASE */
u8MacAddr[0] = 0x01;
u8MacAddr[1] = 0x23;
u8MacAddr[2] = (uint8_t)(0x000000FF & (HAL_GetUIDw0() >> 0));
u8MacAddr[3] = (uint8_t)(0x000000FF & (HAL_GetUIDw0() >> 16));
u8MacAddr[4] = (uint8_t)(0x000000FF & (HAL_GetUIDw1() >> 0));
u8MacAddr[5] = (uint8_t)(0x000000FF & (HAL_GetUIDw2() >> 24));

But there's still the option to edit the MAC via UART and store and load it from SPI flash.

But @Piranha 's idea with the CRC sounds even better, I'll take a look at that.

[t.decker]

We use the I2C EEPROM 24AA025E48 from Microchip, which comes with an official pre-programmed MAC address in a read-only section of the memory.

[Piranha]

Also change the value of the first byte to 0x02 or something else with that second bit set so that it makes a locally administered address. The 0x01 bit makes a group (multicast/broadcast) address.

[LCE]

Wow, never heard of that!
For the first 2 bytes, in my current development, I'm using actually some other "constant" with 0xE as lower nibble, don't know why I changed that when I copied that here.
But good to know anyway, thanks!

[Zzaaack]

Hello everyone, 

I actually had the cance to test on a nucleo board configured with a stm32H755 MCU, without any cache configuration enabled but I wasn't able to read any UID data.

According to RM0399 pag 3510, the UID base address is 0x1FF1 E800 on, but if i try to read the content with this function:

__STATIC_INLINE uint32_t LL_GetUID_Word0(void)

{

return (uint32_t)(READ_REG(*((uint32_t *)UID_BASE_ADDRESS)));

}

Provided on other threads here, it doesn't seem to work, I get Hard Faults every time.

Do you have any idea why is that?

Thanks in advance.

Zaack