lwIP SAM7 Rowley demo problems

Kernel
1

dibosco wrote on Monday, November 10, 2014:

Folks,

I’ve spent a day, along with the help of the chaps at Rowley trying to get an old project working that I had going years ago with a much older version of FreeRTOS.

With the up-to-date version of FreeRTOS it will not work.

The lwIP_Demo_Rowley_ARM7 is the project in question. Originally, when I started to compile it this time round I had really strange issues whereby when it compiled it only linked in about 5k of code and used less than 1k of RAM. Michael at Rowley gave me a fix for that which I’ll submit as a possible bug fix. I guess it’s an incompatibility issue with an older version of Crossworks.

However, even when the errors were fixed and it compiled correctly, I couldn’t load the program properly and couldn’t erase the flash memory at all.

I’m using the AT91SAM7X-EK and I know it’s not an issue with that, because an “hello world” program loads and executes just fine.

So, I recreated the whole project with v3 of Crossworks and that does now program the flash just fine. However, it crashes in portRESTORE_CONTEXT() in portmacro.h which is called from vPortISRStartFirstTask

I believe I am using the correct portmacro.h file. I am sure it is the same one that was in the original demo.

The preprocessor and the portmacro says the code should be:


LDR		R0, =pxCurrentTCB
LDR		R0, [R0]
LDR		LR, [R0]
LDR		R0, =ulCriticalNesting
LDMFD	LR!, {R1}
STR		R1, [R0]
LDMFD	LR!, {R0}
MSR		SPSR, R0
LDMFD	LR, {R0-R14}^	
NOP	
LDR		LR, [LR, #+60]
SUBS	PC, LR, #4

However, the dissasembled code is this:

    E59F004C    ldr r0, 0x00103910
    E5900000    ldr r0, [r0]
    E590E000    ldr lr, [r0]
    E59F0044    ldr r0, 0x00103914
    E8BE0002    ldm lr!, {r1}
    E5801000    str r1, [r0]
    E8BE0001    ldm lr!, {r0}
    E169F000    msr spsr_cf, r0
    E8DE7FFF    ldmia lr, {r0-lr}^
    E1A00000    mov r0, r0
    E59EE03C    ldr lr, [lr, #0x3C]
    E25EF004    subs pc, lr, #4
    E59F3014    ldr r3, 0x00103908
    E5933000    ldr r3, [r3]
    E59F3010    ldr r3, 0x0010390C
    E5933000    ldr r3, [r3]

It’s at the line of disassembled code:


   E25EF004    subs pc, lr, #4

That is crashes, although the few lines above differ from what is, supposedly the source code.

lr contains 0x00001a20
pc contains 0x001038e8

Does that give enough info to maybe point me in the direction of why this is crashing?

Many thanks,

Rob

2

rtel wrote on Monday, November 10, 2014:

Gosh, that is very old, and probably using a very old version of lwIP too.

The assembly seems to match.

Are you sure the CPU is in Supervisor mode when main() is called? That is a requirement for ARM7 ports.

Regards.

3

dibosco wrote on Monday, November 10, 2014:

I know it’s old, but it’s as much about learning about lwIP as anything and I happen to have an old SAM7X-EK!. :slight_smile:

I have no idea whether it’s in supervisor mode. How do I tell?!

Thanks!

4

rtel wrote on Monday, November 10, 2014:

The ARM7 has various different modes, each of which has its own stack.
For example there is User mode, IRQ mode, SVC mode, System mode (user
mode but privileged), etc.

Look at the C start up code - that is the code that is called
immediately from the reset vector. You should see that the first thing
it does is set up a stack for each mode. FreeRTOS only needs a stack
for IRQ mode and Supervisor mode. Tasks run in System mode, but the
stack comes from the FreeRTOS heap, so you don’t need to set one up in
the start up code.

The start up code will enter one mode, set up the stack for that mode,
then enter another mode and set up the stack for that mode, etc. until
all the stacks have been set up.

In that sequence of code you want to ensure the last mode it enters, and
therefore stays in, is Supervisor mode. You also want to ensure that it
never enters User mode, as it is hard to get out of again (requires an
SVC call), and you don’t need to set up a stack for that mode anyway.

For more information you would need to read the ARM documentation for
the ARMv4T architecture.

Regards.

5

rtel wrote on Monday, November 10, 2014:

By the way - did you know FreeRTOS has its own TCP/IP stack now?
http://www.FreeRTOS.org/tcp - we don’t have a port for the SAM7X, but we
do for the SAM4 (which is effectively a newer version of the MCU with a
more modern core).

The SAM4 port is not published, but it could be if you wanted it.

Regards.

6

dibosco wrote on Monday, November 10, 2014:

Well, it’s funny you should say that, because long term, I want to use the SAM4 in production! I assume it’s the SAM4E the port is for? Is it a gcc project? If so, it shouldn’t be too hard for me to get it going on Crossworks.

I didn’t know there was a FreeRTOS TCP/IP stack. I’ll have a look. I need NTP or SNTP and HTTP as well as being able to have a UDP and HTTP sockets open at the same time.

Thanks for the info on Supervisor mode, I’ll investigate.

7

heinbali01 wrote on Wednesday, November 12, 2014:

I didn’t know there was a FreeRTOS TCP/IP stack

“FreeRTOS+TCP” has only been released about 2 weeks ago.

I assume it’s the SAM4E the port is for?

Indeed, it has (will have) a SAM4E “port” and it can be used in a gcc project.

I liked working with the SAM4E. It has a parallel MCI bus, for which there is a good driver in the ASF, giving fast access to an SD-card.
Just make sure you’ll get enough and fast (S(D))RAM. The external SRAM mounted on the “SAM4E Xplained” board is a bit slow.

I need NTP or SNTP

NTP servers can easily be accessed but there is no standard driver yet.
FreeRTOS+TCP has DNS queries (of course), so you can look-up e.g .“0.europe.pool.ntp.org”, send a UDP query and receive a reply.

HTTP as well as being able to have a UDP and HTTP sockets open at the same time.

“UDP and HTTP sockets”? You mean TCP sockets?

It works with BSD-style sockets:

    sock = FreeRTOS_socket(dom, type, prot);
    FreeRTOS_bind(sock, addr, len);
    FreeRTOS_listen(sock, backlog);

    sock2 = FreeRTOS_accept(sock);

    rc = FreeRTOS_select(set, tmout);

You can open as many sockets as malloc() allows you to open.

It shouldn’t be too difficult to port software / drivers that already use standard BSD-style sockets.

Regards.

8

dibosco wrote on Thursday, November 13, 2014:

I do, indeed, mean TCP sockets. I meant that I need to be an HTTP client with one of the [TCP] sockets. Something which I’ve sussed out using lwIP on the SAM7X.

I don’t envisage needing any external RAM. For what I am doing the 128k should be ample.

How far off is it from being available? I have v8.1.2 and I can’t see there being much in the way of networking in that SAM4E project. Although to be fair, I can’t open the project as it’s an Atmel Studio project and I don’t run Windows to be able check it. Actually, I do have a Windows laptop that I could in theory use, but it falls over when you try to install .NET which you need for the bloat fest that is Atmel Studio.

I was actually planning on stitching lwIP into the existing SAM4E demo once I’d got it working under Crossworks. I realise that might be a seriously tricky thing to achieve, but I was hoping that as it had UDP support the low level stuff would be sorted and I could pass it to lwIP instead of the UDP implementation I believe it has.

In fact, having just been a checked, it says on the web site is the FreeRTOS stack, so if there is also TCP available it might save me load of work.

Many thanks for the info. :~)

Rob

9

heinbali01 wrote on Friday, November 14, 2014:

Hi Rob,

Just to be clear: FreeRTOS+UDP already existed for quite a while. Recently this library has been extended to include TCP and some more higher protocols, and since then it is called FreeRTOS+TCP.

I meant that I need to be an HTTP client with one of the [TCP] sockets

That’s what I also often need, either to download a file from the web, or to stream audio from a web radio.

For what I am doing the 128k should be ample.

Of course yes, and it is also more than enough to run a full TCP/IP stack (I am, as an audio freak, always thinking in MB’s).

How far off is it from being available?

If you want today, but it will be a non-official try-out release.

I have v8.1.2 and I can’t see there being much in the way of networking in that SAM4E project.

Due to lack of time, it hasn’t been made public yet.

Atmel Studio, Rowley’s Crossworks…

Normally it is easier and recommended to start with a FreeRTOS demo project, things will work straight out of the box :slight_smile:

But if you feel comfortable using Crossworks, give it a try. I am not sure about accessing the GMAC and Ethernet PHY: the network interface driver uses source files from Atmel’s software framework ASF. Could that be combined in your Crossworks project?

Regards,
Hein

10

dibosco wrote on Friday, November 14, 2014:

Hi Hein,

Many thanks for the info.

I have actually taken three Atmel Studio FreeRTOS demos and turned them into Crossworks demos: SAM3S, SAM4S and the SAMD20 projects (the latter was the trickiest in many ways) - they all use Atmel’s ASF.

So, it’s not that difficult, despite the staggeringly arcane ASF files. Crossworks is gcc and Atmel studio is gcc, so it shouldn’t be that tricky; in theory anyway. The ASF files have all sorts of #defines for all their different processors and also to select between IAR and gcc. It can get very hard to follow code at times with them.

So, in short, yes please, I would very much like to try the SAM4E project with FreeRTOS TCP/IP! How do we achieve this?

Thanks again,

Rob

11

rtel wrote on Friday, November 14, 2014:

How do we achieve this?

We are just discussing whether to send them directly, or just upload
them to the website.

12

heinbali01 wrote on Friday, November 14, 2014:

Hi Rob,

If you send a message to info at freertos point org (if I’m not mistaken), Richard will send you a ZIP file.

turned them into Crossworks demos: SAM3S, SAM4S and the SAMD20 projects

It sounds like you a die-hard programmer :slight_smile:

For SAM4E we did use the latest SAM4E ASF files. The drivers that were needed were all OK.
Some changes were made to ethernet_phy.c and gmac.c. You’ll find them in a separate directory.

Regards,
Hein

13

andrehp wrote on Wednesday, May 06, 2015:

Hi,

I know this topic is quite old, but could I get the files for FreeRTOS+TCP for SAM4E?

I haven’t had any luck adapting the example available for Windows to SAM4E.

Thanks,
Andre