FreeRTOS-Plus-TCP on SAME70 and latest code

Partners & Sponsors Microchip
1

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

2

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.

3

It sounds like you have found the right driver.

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.

4

@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
5

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.

6

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 :slight_smile:

#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 ?

7

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 :slight_smile:
#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

8

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.

9

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?

10 
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();
11

Got it working. Thanks for your comments.

12

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.

1 Like
13

Hi @mtut
Thanks a lot for this example :grinning:
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 ?

14

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

15

Thank you for your contribution!

1 Like