FreeRTOS + IwIP Port for LM3S9b96 + eclipse

bodenwelle wrote on Saturday, October 15, 2011:

I already searched the forum for some information but I can’t get the information I need…

I have a Development Kit DK-LM3S9B96 (Texas Instruments) and want to run the newest version of FreeRTOS and lwIP on it. I work with eclipse indigo.

This project is running on my board: (but that is a to old version of freeRTOS)

http://code.google.com/p/lumweb/

then I tried a freeRTOS Demo from here:

http://sourceforge.net/projects/freertos/files/FreeRTOS/V7.0.2/

this is the one I tried: (it comes with the false ip Stack but for the beginning it would be ok)

FreeRTOSv7.0.2\Demo\CORTEX_LM3Sxxxx_Eclipse

I can build it without an error, but every time I write it into the flash from my board and reboot the board, my board is “damaged”. it reacts on nothing, the jtag interface doesn’t work and the reset button doesn’t work. The only way to reset the board is the TI flash programmer. With it I can reconfigure the jtag port to be a jtag port.

So I think there is a basic hardware configuration failure. I am wondering why the demo is called CORTEX_LM3Sxxxx. Where can I tell the application that I have a LM3S9B96? Or should it run on every CORTEX_LM3S… processor without a special hardware configuration?

I tryed to compare some of the configuratoin files like FreeRTOSConfig.h, hw_gpio.h, rom.h, hw_flash.h, cpu.h with the lumweb project (which is running). It wasn’t that easy because the strukture of the lumweb projekt is verry drfferent to the RTOSDemo and also it is another version. So I can’t find something helpful.

Can someone tell me in which files I have to make changes to configure the RTOS for my specific hardware? The only change I made was in FreeRTOSconfig.h

#define configCPU_CLOCK_HZ                ( ( unsigned long ) 50000000 )

I changed the 50000000 to 80000000.

Thanks for your help!

Adrian

rtel wrote on Saturday, October 15, 2011:

I have a Development Kit DK-LM3S9B96 (Texas Instruments) and want to run the newest version of FreeRTOS and lwIP on it. I work with eclipse indigo.

This project is running on my board: (but that is a to old version of freeRTOS)

http://code.google.com/p/lumweb/

then I tried a freeRTOS Demo from here:

http://sourceforge.net/projects/freertos/files/FreeRTOS/V7.0.2/

this is the one I tried: (it comes with the false ip Stack but for the beginning it would be ok)

Which version of FreeRTOS is in http://code.google.com/p/lumweb/ ?  If it is V5 or higher, then it should be 100% backward compatible with FreeRTOS V7 (in theory), and all you need to do is drop the latest files over the top of the older files in your project and rebuild.  If it is earlier than V5 you are using something that is really really old, and there was a change to either the xQueueSendFromISR() or xQueueReceiveFromISR() function (I forget which, without looking it up, but it is documented in http://www.FreeRTOS.org/History.txt) which makes it not quite compatible with V7.

I can build it without an error, but every time I write it into the flash from my board and reboot the board, my board is “damaged”. it reacts on nothing, the jtag interface doesn’t work and the reset button doesn’t work. The only way to reset the board is the TI flash programmer. With it I can reconfigure the jtag port to be a jtag port.

So I think there is a basic hardware configuration failure

I would guess you are correct - but don’t know for sure.  It is probably re-configuring the pins required for your debugger.  It could be other things though.  I would suggest commenting all the code out, then adding bits in one thing at a time until you find the bit that is stopping the debugger working.

I am wondering why the demo is called CORTEX_LM3Sxxxx. Where can I tell the application that I have a LM3S9B96?

The demo was written long before the LM3S9Bx processors came out, but FreeRTOS runs on any Cortex-M device as it only uses the core.  The demo might configure pins for LEDs or a peripheral that is messing you up, but the FreeRTOS kernel itself definitely won’t be.

I presume you have populated the interrupt vector table correctly with the FreeRTOS functions?

If you look at the documentation page for the demo you are using it gives you a list of the hardware it has been tested on.

http://www.freertos.org/portlm3sx965.html

Regards.

bodenwelle wrote on Saturday, October 15, 2011:

Which version of FreeRTOS is in http://code.google.com/p/lumweb/ ?

It is v6 and I already replaced the whole FreeRTOS/source folder witth the newer one.  -> the projekt runs! Till now I don’t want to take this prject as a starting point for my project, because it is verry big and has a confusing stucture. But maybe I should do it…

I presume you have populated the interrupt vector table correctly with the FreeRTOS functions?

No, how can I do it?

If you look at the documentation page for the demo you are using it gives you a list of the hardware it has been tested on. http://www.freertos.org/portlm3sx965.html

I already know this page but my processor isn’t listed.  Can you tell me what kind of changes I exaktly (in which files) have to do, to change form listed processor one to listed processor two (for example form EK-LM3S3768 to EK-LM3S3748)? Or does the demo run without changes on both systems? I always have in mind that I have to tell the OS where (which adress) are for example the GPIO ports. Isn’t that right?
And if I do have to make souch a configuration - in which file?

For the moment I’ll try to minimize the demo to get it running…

Regards!
Adrian

davedoors wrote on Saturday, October 15, 2011:

No, how can I do it?

Look at all the demos for the Cortex in FreeRTOS\Demo, or search this forum. This really should be an FAQ. Here are some examples I found just searching now https://sourceforge.net/projects/freertos/forums/forum/382005/topic/4694403 http://sourceforge.net/projects/freertos/forums/forum/382005/topic/3980798

Can you tell me what kind of changes I exaktly (in which files) have to do

You have to do exactly none to the kernel. As richard has already said, it might be that a demo file is configuring pins that are stopping the debugger working, but to be honest I doubt that. The cortex-m3 port works on all cortex-m3 parts as it does not touch anything outside of the cortex-m3 core itself - no peripherals at all.

bodenwelle wrote on Thursday, October 20, 2011:

now after some hours of work I realized that I have to make a change in the function prvSetupHardware() in mian.c
SysCtlClockSet( SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_8MHZ );
should be:
SysCtlClockSet( SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ );
I was looking for a config file to configure the hardware and I changed the configCPU_CLOCK_HZ in FreeRTOSConfig.h but that wasn’t enough.
Now everything is running.

Regards
Adrian

anonymous wrote on Tuesday, November 22, 2011:

I am using 9B92 kit with CCSv4 for freeRTOS 7.02 and LwIP implementation. Every thing seems running fine but have few questions.

1) I have a task with hard timing requirement of 1 ms. If I run this task at higher priority then ethernet task, DHCP can not find IP address.

2) If I run hard timing requirement task at lower priority then ethernet task, DHCP works fine.

I want hard timing task to run at highest priority,

Any hint.

davedoors wrote on Wednesday, November 23, 2011:

It sounds like your 1 ms task is starving lower priority tasks of CPU time, so if it was not the DHCP it would be something else. I suggest doing the 1 ms processing in an interrupt triggered by a timer. If you set the priority of the interrupt above configMAX_SYSCALL_INTERRUPT_PRIORITY (so a lower numerical value) then the interrupt will be very accurate but can’t use freeRTOS calls.

richard_damon wrote on Wednesday, November 23, 2011:

How have you implemented this 1ms “hard real time” task? What is it waiting on so that it starts it processing, and how is it telling the system it is done (this may be the same thing).

How much time is it going to take to do it processing every 1ms.

All tasks (except maybe idle priority tasks) should have in their processing loop some form of a “wait for something” be it time or a semaphore or queue to tell them to start up. If they don’t, then they will naturally just take up all the processor time at that level and not let lower priority tasks run. Note that a “Yield” doesn’t really count, as  that will let other tasks of the SAME priority run, but not lower.