FreeRTOS-Plus-TCP on SAME70 and latest code

charliefjohnson · October 8, 2021, 10:05pm

Does anyone have a functional FreeRTOS-Plus-TCP on a SAME70 ??
I’m using the a FreeRTOSIP_config.h I found thru this form but am on the current tip of master for the FreeRTOS-Plus-TCP git repo. The Phy seems to be discovered just fine.
(PhyId: 0x00221560)

I’m not very familiar with DriverSAM driver. It seems like it is never thinks there is a Link. The prvEMACHandlerTask() is just spinning. The GMAC_Handler() never is invoked.

We have the LWIP based network stack working fine on this hardware (It is a custom board) but were trying to decide if the FreeRTOS-Plus-TCP might be a better choice.

A know good FreeRTOSIP_config.h would be be nice to compare against.

Thanks

rtel · October 9, 2021, 7:42pm

From your description it doesn’t sound like a configuration file issue. Are the lwIP and +TCP MAC drivers using the sam low level driver libraries? If so, can you step through both in the debugger to see the differences? Especially the part that decides if the link is up or not.

htibosch · October 11, 2021, 9:18am

It sounds like you have found the right driver.

EDIT link updated on jan 21, 2025

It combines the drivers for SAM4E and SAME70.

There is a demo project for SAME70 which uses mentioned driver in a Makefile project.

I’m using the a FreeRTOSIP_config.h

Mind you that the correct name is FreeRTOSIPConfig.h, without an underscore.

htibosch · October 11, 2021, 9:39am

@rtel wrote:

Are the lwIP and +TCP MAC drivers using the sam low level driver libraries?

+TCP uses the GMAC driver as it was created by Atmel (Microchip), but with some changes:

allow zero-copy sending and receiving
several optimisations

charliefjohnson · October 11, 2021, 3:16pm

Sorry, I miss typed it. I am using FreeRTOSIPConfig.h

In comparing the original ASF3 KSZ8081RNA phy driver and I see the following in ethernet_phy_auto_negotiate():

#if BOARD != SAME70_XPLAINED
/*
* Clock input to XI (Pin 8)
*/
ul_phy_ctrl2 = GMII_RMI_REF_CLK_SELECT;
uc_rc = gmac_phy_write(p_gmac, uc_phy_addr, GMII_PCR2, ul_phy_ctrl2);
if (uc_rc != GMAC_OK) {
gmac_enable_management(p_gmac, false);
return uc_rc;
}
#endif

We would be executing this. Not sure why SAME70_XPLAINED doesn’t need it. So I’m going to try and copy this in and try it.

charliefjohnson · October 11, 2021, 4:08pm

Here’s a difference I noticed with the phy drivers. The ASF3 phy driver had the following definition:

#define GMII_PCR1        0x1E   // PHY Control 1
#define GMII_PCR2        0x1F   // PHY Control 2

In the FreeRTOS-Plus-TCP/portable/NetworkInterface/Common/phyHandling.c

#define phyREG_19_PHYCR     0x19U /* 25 RW PHY Control Register */
#define phyREG_1F_PHYSPCS   0x1FU /* 31 RW PHY Special Control Status */

Are these referring to the same register ?? Should the 0x19U be 0x1EU ?

htibosch · October 12, 2021, 6:24am

You wrote:

Here’s a difference I noticed with the phy drivers.
The ASF3 phy driver had the following definition:

#define GMII_PCR1 0x1E // PHY Control 1
#define GMII_PCR2 0x1F // PHY Control 2

In the FreeRTOS-Plus-TCP/portable/NetworkInterface/Common/phyHandling.c
#define phyREG_19_PHYCR 0x19U /* 25 RW PHY Control Register */
#define phyREG_1F_PHYSPCS 0x1FU /* 31 RW PHY Special Control Status */

Are these referring to the same register ?? Should the 0x19U be 0x1EU ?

Note that the Atmel driver defines GMII_PCR2, but it does not use it. It defines and is also uses the first register GMII_PCR1.

phyHandler.c also refers to this register here:

pxPhyObject->fnPhyRead( xPhyAddress, 0x1E, &ulControlStatus );

I should have given it a proper name, something like PHY_Control_1, in stead of the number 0x1E. PHY_Control_1 is very specific for this PHY.

The module common/phyHandling.c is a generic PHY-driver. It has also been used and tested on KSZ8081 (E70-Xplained). I just retested it on my SAME70-XPLD board, and it worked fine.
I saw this logging:

[IP-task   ] PHY ID 221560
[IP-task   ] xPhyReset: phyBMCR_RESET 0 ready
[IP-task   ] +TCP: advertise: 01E1 config 3100
[IP-task   ] prvEthernetUpdateConfig: LS mask 00 Force 1
[IP-task   ] Autonego ready: 0000786d: full duplex 100 mbit high status

The PHY-driver creates some logging by calling FreeRTOS_printf(). Can you somehow make this logging visible?

You wrote:

#if BOARD != SAME70_XPLAINED
/*
* Clock input to XI (Pin 8)
*/
ul_phy_ctrl2 = GMII_RMI_REF_CLK_SELECT;
uc_rc = gmac_phy_write(p_gmac, uc_phy_addr, GMII_PCR2, ul_phy_ctrl2);
if (uc_rc != GMAC_OK) {
gmac_enable_management(p_gmac, false);
return uc_rc;
}
#endif

I do not have this code. Both my SAME70 and SAM4E projects use the generic PHY driver.
It looks like this is part of Atmel’s PHY driver, which you do not need if you are using phyHandling.c

charliefjohnson · December 15, 2021, 12:26am

Any guess on what might be causing the following debug output:

prvIPTask started
PHY ID 22156xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 3100
prvEthernetUpdateConfig: LS mask 00 Force 1
xPhyStartAutoNegotiation: phyBMCR_RESET timed out ( done 0x00 )
Network buffers: 16 lowest 16
Queue space: lowest 25
Socket 80 → 0ip:0 State eCLOSED->eTHeap: current 53512 lowest 535Queue space: lowest 24

I’m assuming the line:

xPhyStartAutoNegotiation: phyBMCR_RESET timed out ( done 0x00 )

indicates that the phy isn’t coming out of reset ?? Any suggestions.

rtel · December 15, 2021, 12:28am

I’ve not reviewed the rest of the thread so this may be a non-answer - but are you sure you have enabled the clock to the MAC and configured the IO between MAC and PHY?

charliefjohnson · December 15, 2021, 3:10pm

static void vEthernetInit()
{
        pio_set_output(PIN_GMAC_RESET_PIO, PIN_GMAC_RESET_MASK, 0,  false, true);
        pio_set_input(PIN_GMAC_INT_PIO, PIN_GMAC_INT_MASK, PIO_PULLUP);
        pio_set_peripheral(PIN_GMAC_PIO, PIN_GMAC_PERIPH, PIN_GMAC_MASK);

        /* Configure GMAC runtime clock */
        gmac_set_mdc_clock(GMAC, sysclk_get_cpu_hz());
        /* Enable GMAC clock */
}


This is called from main:

int main(void) {

const usart_serial_options_t usart_serial_options = { .baudrate =
            CONF_UART_BAUDRATE, .charlength = CONF_UART_CHARLENGTH, .paritytype =
CONF_UART_PARITY, .stopbits = CONF_UART_STOPBITS, };

irq_initialize_vectors();
cpu_irq_enable();

    /* Initialize the SAM system. */
sysclk_init();
board_init();

pmc_enable_periph_clk(ID_GMAC);

vEthernetInit();

charliefjohnson · December 20, 2021, 4:46pm

Got it working. Thanks for your comments.

mtut · August 30, 2023, 9:52pm

In case anyone else is looking for this in the future, there is an example application on the SAME70 using the most recent (202210.01 LTS) LTS libraries here.

karahulx · August 31, 2023, 9:14am

Hi @mtut
Thanks a lot for this example
It would be highly helpful for someone starting out with FreeRTOS + TCP on SAME70 platform. Just curious if any changes would be needed for porting the same example to latest FreeRTOS+TCP V4.0.0 ?

mtut · August 31, 2023, 4:54pm

Of course @karahulx !
It works in backwards compatibility mode, but I can migrate that over. There’s an issue here.

Update: There is now a release branch with the latest kernel (10.6.1) and FreeRTOS+TCP V4.0.0

aggarg · September 4, 2023, 5:07am

Thank you for your contribution!

sidket · January 21, 2025, 10:41am

Hi htibosch,
I am trying to build Makefile for SAME70 individually but fails as attached in image. Please suggest what am I doing wrong?

karahulx · January 21, 2025, 1:43pm

Hi @sidket
The command you give make Makefile seems incorrect.
make always reads from the file named “Makefile”, no need to mention it explicitly, unless you are not sure which makefile to build the project from. In that case, you need to use the -f flag.

You can try to build using make , make . or make -f Makefile

sidket · January 22, 2025, 3:35am

Hi Rahul Thank you for your response. Still no luck. I am right in the src directory and trying to make SAME70 project. Could you please check image attached. How should I get it built. Is it for linux only? As I am on Windows10.

karahulx · January 22, 2025, 4:02pm

Hi @sidket
This project seems very old , because the TCP versions being used are outdated and multiple APIs being used have already been deprecated or changed to newer APIs. I was able to build it successfully on Ubuntu 20.04 with the following changes , but a lot of linker errors exist.

Download gcc-arm-none-eabi-9-2020-q2-update in your /home/ubuntu folder.
Make the changes in config.mk file

ifeq ($(ipconfigMULTI_INTERFACE),true)
	DEFS += -D ipconfigMULTI_INTERFACE=1
	PLUS_TCP_PATH = \
		$(GEN_FRAMEWORK_PATH)/FreeRTOS-Plus-TCP-multi
else
	DEFS += -D ipconfigMULTI_INTERFACE=0
	PLUS_TCP_PATH = \
		$(GEN_FRAMEWORK_PATH)/FreeRTOS-Plus-TCP.v2.3.4 #this is changed
endif

PROTOCOLS_PATH     = $(PLUS_TCP_PATH)/source/protocols

C_SRCS=
CPP_SRCS=
S_SRCS=

DEFS += -DBOARD=$(MY_BOARD)
DEFS += -DFREERTOS_USED
DEFS += -D__ATSAME70Q21__=1
DEFS += -D__SAME70Q21__=1

# SAME70 will be define automatically
# DEFS += -DSAME70=1

INC_PATH =

#this line is added
INC_PATH += \
	$(PLUS_TCP_PATH)/source/include/

INC_PATH += \
	$(PLUS_TCP_PATH)/source/portable/NetworkInterface/DriverSAM/

Make using the following command make USE_IPERF=0 , since the file used for performance is not present in the repository. It throws the error
fatal error: iperf_task.h: No such file or directory
Another file FreeRTOS_TCP_server.h seems to be not present, due to which compilation is failing , I currently commented them out in main.c and UDPLoggingPrintf.c.

You can try these steps out in Windows if possible, but I would suggest to create a new project using this as a reference with latest versions of FreeRTOS Kernel and FreeRTOS TCP.

Thanks.

sidket · January 23, 2025, 9:05am

Thanks Rahul, Yes after asking again and again about making this project got no response, I gave up because my actual task was something else and making it work became another one.
now I am using demo project from github[dot]com[slash]Peter-Herrmann[slash]SAME70-FreeRTOS-Plus-TCP , and modifying it to get my solution.