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);
}

 

[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.

[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!

[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.

[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!

[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.

[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

 

[Johi]

Have you checked your hypothesis related to MAC with Wireshark or the like?

Do you use Modbus TCP or Modbus UDP?

I have developed a Modbus TCP/IP (OS free) server running (multi-client) on STM32F407 and saw that Wireshark even is able do decode Modbus TCP/IP.

[Pavel A.]

>As soon as I connect a second identical board but with different IP (verified)

Pardon me, no offence meant, but things happen.... verified how? Any chance of duplicate MAC address?

 

[Zzaaack]

@Johi and @Pavel A. Thanks for you reply, but the MAC issue was already addressed in the previous messages. That was the issue in fact.

The solution of having a UID to set a "unique" MAC address is very interesting and I'm trying to implement it.

The issue, as you can read in the last message I sent, is that reading the UID base address I get hard fault. It was written somewhere that reading such registers with Icache active was not possible. I tried to do it with a dedicated project and still got the hard fault. I am asking now if there is something I'm doing wrong on my H755 nucleo board.

 

Thanks

[Piranha]

Check the actual compiled UID address with disassembler. If that one is correct and you still cannot read the UID, then there is something else that is wrong. Check the stack address and whether that is 8-byte aligned. Or it could be something "unrelated", which just happens to be triggered indirectly.