# FreeRTOS+TCP on Zynq fails silently when ucMACAddress not defined

**URL:** <https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191>\
**Category:** Libraries\
**Created:** [August 9, 2021, 8:24pm UTC](https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191 "2021-08-09T20:24:09Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![chafla](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chafla/32/1827_2.png) [@chafla](https://forums.freertos.org/u/chafla)\
**Post date:** [August 9, 2021, 8:24pm UTC](https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191/1 "2021-08-09T20:24:09Z")

</div>

Using a zynq board, I spent a good bit of time scratching my head recently trying to figure out why networking with FreeRTOS+TCP would seem to init but silently fail. Every sign seemed to show that the networking stack was up and ready to process events, but the board refused to receive or send any sort of network traffic. Pings were ignored, TCP connections were ignored, and wireshark showed no sort of acknowledgement from the board’s IP.  
The solution that I discovered came after retrying a demo program, and noting that it defined `ucMACAddress` in main.c. Despite the fact that I had passed the same exact MAC address into `FreeRTOS_IPInit`, that value was only used later in the initialization process. Instead, `ucMACAddresss` is defined as extern in the associated `NetworkInterface.c` for Zynq.

It was pretty unclear that setting `ucMACAddress` in `main.c` was crucial for the networking stack to come up at all (save for a single comment in `NetworkInterface` over the variable itself), and that it was separate from the mac address parameter passed into FreeRTOS\_IPInit(). Not only that, but there were absolutely zero indications or messages indicating that the value was unset. It seems like an assert or printf indicating the unset value would have made the problem a lot clearer and easier to diagnose.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [August 9, 2021, 11:15pm UTC](https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191/2 "2021-08-09T23:15:47Z")

</div>

If I understand you correctly - the Ethernet source file was referencing an extern variable, but that variable was not defined. I would expect that to result in a linker error though - so am misunderstanding?

---

<div class="post-metadata">

**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\
**Post date:** [August 10, 2021, 4:26am UTC](https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191/3 "2021-08-10T04:26:34Z")

</div>

@chafla, thanks a lot for reporting this.

@rtel wrote:

> the Ethernet source file was referencing an extern variable, but that variable was not defined

I understand that it was defined somewhere, but it was not properly initialised.

I’m very sorry for the trouble that you went through. Today I will propose a patch that should avoid this.

Background: in the demos of FreeRTOS+TCP, the MAC-address is defined in a global variable in main.c:

```c
/* MACAddress as it appears in main.c */
const uint8_t ucMACAddress[6] =
{
    configMAC_ADDR0,
    configMAC_ADDR1,
    configMAC_ADDR2,
    configMAC_ADDR3,
    configMAC_ADDR4,
    configMAC_ADDR5
};

```

And this is how `FreeRTOS_IPInit()` is called:

```c
FreeRTOS_IPInit( ucIPAddress, ucNetMask, ucGateway, ucDNS, ucMACAddress );

```

The Zynq driver, like most other drivers, is relying on this const array.

What we can do is replace `ucMACAddress` with `ipLOCAL_MAC_ADDRESS`, which is a copy of the MAC-address set by [`FreeRTOS_IPInit()`](https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/c1ce466e9697a8664287030567fedbfe2a303330/FreeRTOS_IP.c#L1258):

```c
    /* The 'ucMACAddress' in this statement refers to a function parameter.,
     * and not the global variable. */
    memcpy( ipLOCAL_MAC_ADDRESS, ucMACAddress, ( size_t ) ipMAC_ADDRESS_LENGTH_BYTES );

```

I will prepare a pull-request for this.

---

<div class="post-metadata">

**Author:** ![gedeonag](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/gedeonag/32/479_2.png) [@gedeonag](https://forums.freertos.org/u/gedeonag)\
**Post date:** [August 14, 2021, 3:12am UTC](https://forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191/4 "2021-08-14T03:12:08Z")

</div>

> <https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/pull/304>
>
> Description
> \-----------
> In response to a \[post on the FreeRTOS forum\](https://…forums.freertos.org/t/freertos-tcp-on-zynq-fails-silently-when-ucmacaddress-not-defined/13191), I want to propose to stop referring to the global:
> ~~~c
> const uint8\_t ucMACAddress\[6 \];
> ~~~
> and in stead use library macro \`ipLOCAL\_MAC\_ADDRESS\`, which points to the location where the IP-stack stores the configured MAC-address.
> 
> Test Steps
> \-----------
> I compiled the Zynq project and ran it.
> 
> Related Issue
> \-----------
> Most users do not encounter the problem, as they define the global variable like this:
> ~~~
> const uint8\_t ucMACAddress\[6 \] =
> {
> configMAC\_ADDR0,
> configMAC\_ADDR1,
> configMAC\_ADDR2,
> configMAC\_ADDR3,
> configMAC\_ADDR4,
> configMAC\_ADDR5
> };
> ~~~
> where \`configMAC\_ADDR\[0-5\]\` is defined in the FreeRTOSConfig.h
> 
> By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.