FreeRTOS+TCP on SAME70 with ASF4 (Atmel Start) MAC drivers

Kernel
1

skjafar wrote on Wednesday, October 10, 2018:

I have been trying to get the TCP stack to work with the ASF4 drivers from Atmel from SAME70, and I am having a ton of problems, mainly with “interface.c”, it seems I have to rewrite it from the ground up, and I do not have a lot of Networks knowledge to do that properly.

I have used a version of the driver provided here on the forum, but that uses ASF3 drivers.

Has anyone been successful in getting FreeRTOS TCP stack running with the new drivers from Atmel?

2

heinbali01 wrote on Wednesday, October 10, 2018:

Hi Sofian. If you want, write an email to me: hein [at] htibosch [dot] net
Developing an Ethernet driver involves lots of technical details, and it will be quicker if we handle this by email.

3

jiggerherman wrote on Friday, October 12, 2018:

Hi: I am in a similar situation.

I have FreeRTOS ported and running well on SAME54 (using ASF4 / Atmel START), and would like to add FreeRTOS+TCP. I have looked at Atmel’s lwIP demo (for SAME54, which has MAC/PHY drivers that work with ASF4). I also have looked at FreeRTOS+TCP demo for SAM4E (which uses ASF3 drivers).

Can you forward or reply with any suggestions - I expect I’ll have same issues that Sofian had.

4

skjafar wrote on Wednesday, November 07, 2018:

Hi,

After a lot of help from Hein I was able to get it all running on both ASF3 and ASF4 for the SAME70-Xplained board with SAME70Q21A not B.

Below are links for example projects, one using ASF3, it’s a very simple example. The second is using ASF4, aka Atmel Start.

They both start looking for a DHCP server upon wake up for a valid connection, if not found they will switch to the defined static IP.

Details on the ASF4 project:

  • UART using the debug board at 115200 baud, this should give you periodic statistics.
  • After TCP connection you will see the IP address, connect to it using telnet at port 2008, it has FreeRTOS+CLI implemented there, type “help” for the command list.
  • You can use Atmel Start to add drivers but make sure to do the following afterwards:
    • Never allow modifications on the FreeRTOS files even if it asks.
    • Never allow modifications on FreeRtosConfig.h
    • Modify the linker scripts as shown in directory: Device_Startup. Read “AddMeToldFiles.txt”
    • Add “#include “application_include.h”” to “driver_init.h”
    • add “init_application();” into “void system_init(void)” in file “driver_init.c”
    • if you see file name “main.c” in root directory remove it.

If you decide to get the FreeRTOS+TCP part into your project make sure to change the linkerscript to accomedate the change, mainly defining the following right after the .text part of memory. :

.first_data (NOLOAD) :
{
. = ALIGN(4);
_first_data = . ;
(._first_data ._first_data.)
. = ALIGN(4);
_e_first_data = . ;
} > ram

Please note that the gmac driver included with FreeRTOS+TCP for SAME70 cannot run with CACHE enabled, at least not yet, maybe Hein can comment on this, and if you do get it running please let us know.

I hope this benifets you.

The links:
ASF3: https://drive.google.com/open?id=1WBOGMzwHGw5X35h51ABLxd6CNs6_WYmW
ASF4: https://drive.google.com/open?id=1gfFz7jkVkEAZap2RYFdMlC34c_Nfp5f9

I will try to keep the links as long as possible. I have also attached the files.

Thanks Hein.

5

heinbali01 wrote on Thursday, November 08, 2018:

Hi Sofian, thanks a lot for all this work, and thanks for sharing it in this forum.

Please note that the gmac driver included with FreeRTOS+TCP
for SAME70 cannot run with CACHE enabled

When I find the time, I will look at the DCACHE again. That will not be before December this year.

Thanks!

6

heinbali01 wrote on Thursday, November 08, 2018:

Hi Sofian,

Thanks man, good work!

On 11/8/2018 01:02, Sofian Jafar wrote:

The links:
ASF3: SAME70-Xplained-FreeRTOS+TCP_ASF3.zip - Google Drive
ASF4: SAME70-Xplained-FreeRTOS+TCP_ASF4.zip - Google Drive

I will try to keep the links as long as possible. I have also attached the files.

Do you have experience with github.com ? Do you have an account?

That is a nice way of sharing software with the public.

github.com is without charge, unless you want to have private repositories.

7

skjafar wrote on Thursday, November 08, 2018:

Actually I use git regularly, but I thought some people might not be as familiar, that is why I have attached them as zip files.

It’s a good suggestion, I will add them soon to my GitHub repo and post back.

8

mikeraw wrote on Friday, December 21, 2018:

Hi, I ran the ASF4 files, and that works. Impressive!

But I saw that the project was build on FreeRTOS version 9, not the newest version 10. Any plan to change this? They use two different lisenses, so I am a little afraid to mix between them. Should I downgrade my entire project to version 9? Thinking…

By the way, I think the D-cache “problem” should be solved by using TCM. I believe it is just a matter of adding the proper attribute to all memory shared by interrupts and tasks. I have the TCM working with DMA etc. Works perfectly. Furthermore. all interrupt code should also have the attribute for TCM set, as it will make it faster. The entire FreeRTOS and TCP stack would benefit by running from the TCM.

9

rtel wrote on Friday, December 21, 2018:

It would be nice if the FreeRTOS version in ASF was updated, but the ASF
is not distributed by us.

10

eduardo-petards wrote on Wednesday, March 27, 2019:

I have tried to generate an executable using the SAME70-Xplained-FreeRTOS+TCP_ASF4.zip file using Eclipse.
In my attempt however to create a project I have found that the file sam.h, and the others that this file includes, are not present. There are several c files that include sam.h
The problem was solved by having these files copied from a FreeRTOS distribution.
Ids it possible that project that you have created has a link to a directory outside your project?

I’m also facing another regarding the definition of Gmac in NetworkInterface.c (line 255).
typedef struct gmac_device {
/** Pointer to HW register base */
Gmac *p_hw;

I cannot find the file that defines Gmac! Any ideas about this?

11

eduardo-petards wrote on Wednesday, March 27, 2019:

I found gmac.h in fact 2 of them… one full of defines in instance and another with IOs and defines in component.
They are both included by same70q21.h which also includes many files in component and in instance.
I was seeing the file SAME70-Xplained-FreeRTOS+TCP_ASF4.zip has a complete solution but it seems to be dependable of an instalation of FreeRTOS and ASF.
Would this be the case?

12

heinbali01 wrote on Friday, March 29, 2019:

Hi Eduardo, I also get lost here. Hopefully there are other users who can shed some light on this.

I know about the 2 occurrences of gmac.h : one is a description of registers and hardware, the other contains prototypes of functions and variables.

I published a driver that is compatible with SAME70 as well as SAM4E here
Maybe that works better for you.
Whait I did is take a copy of gmac.c, change it to my wishes, and called it gmac_SAM.c, c.q.
gmac_SAM.h. But when you compile that interface, you may well get stuck on compilation errors because the version of your frame doesn’t fit. Sigh…

The problem is that the Atmel Framework changes more quickly that we have the time to adapt the existing +TCP drivers.

13

eduardo-petards wrote on Monday, April 01, 2019:

There is also the matter of the definition of SAME70

In parts.h is defined as:
define SAME70 (SAME70J || SAME70N || SAME70Q || SAME70JB || SAME70NB || SAME70QB)

In FreeRTOSIPConfig.h is defined as:
define SAME70 1

14

jarni wrote on Sunday, June 30, 2019:

On NetworkInterface.c, in prvGMACInit function, I had to do this modification:

		//xPhyDiscover( &xPhyObject );
        while(xPhyDiscover( &xPhyObject ) < 1);

since sometimes the PHY is not ready and xPhyDiscover fails and is never called again.

15

jarni wrote on Sunday, June 30, 2019:

And I’m working on SAME70Q21B, it seems working well.

16

Sorry for the thread revival; any chance the SAME70 drivers are still available? I’m unable to access the previous SourceForge links.

I’m looking to get +TCP working in the Atmel Studio FreeRTOS 10.0.0 example application with the ATSAME70Q21.

Thanks!

17

No problem to revive an old thread.

You can find all FreeRTOS+TCP drivers on Github here.

But… the driver for SAME70 is not there, only an old driver called ‘ATSAM4E’.

Here’s a copy of the driver that you probably found on SourceForge:

SAME70_plus_tcp_driver.zip (54.4 KB)

And here is the latest driver, that should work for both SAM4E and SAME70:

DriverSAM_plus_tcp_driver.zip (24.2 KB)

I recommend using the last driver because it is the newest. Please report how it goes.

I will prepare a pull request so it will be added to the repository on Github.

18

Brilliant, thanks Hein, much appreciated.

I’ll certainly report back.

19

Hi Hein,

I’ve got the SAME70 main_blinky program working with 10.3.0. I’m now adding +TCP and have come across a few minor issues. I’m happy to capture these on Github or elsewhere if that’s preferred.

  1. I needed to add the xCheckLoopback prototype and function to the FreeRTOS_ARP.[ch] files per this post on SourceForge. With xCheckLoopback successfully incorporated into FreeRTOS_ARP.[ch], I’ve now removed tcp_loopback.c from the project.

  2. The provided NetworkInterface.c file for SAM4E/SAME70 uses a (seemingly) outdated usGenerateProtocolChecksum function. The function in NetworkInterface.c is missing the second size_t uxBufferLength parameter. The calling function vGMACGenerateChecksum is called from gmac_dev_write in the provided gmac_SAM.c driver. Am I correct in my understanding that the ul_size (length of the frame) parameter in gmac_dev_write could be passed to vGMACGenerateChecksum to be used as the uxBufferLength parameter in usGenerateProtocolChecksum? I’m not entirely sure if the ‘frame length’ is equal to the ‘buffer size’ in this case.

I’ll have a go at getting the basic TCP echo example working in the meantime.

20

Implementing xCheckLoopback()` is only useful if you plan to send packets to your own (MAC-) address. It was a try-out, and I never found the time to get it into mainline.

usGenerateProtocolChecksum(): sorry, yes the later implementation also wants to know the length of the packet. This call should do it.

   usGenerateProtocolChecksum( pxBuffer->pucEthernetBuffer,
                               pxBuffer->xDataLength,
                               pdTRUE );

Thanks for reporting back. I will change these two things. Hein