FreeRTOS + Rowley + Olimex SAM7-P256

studionebula wrote on Thursday, July 03, 2008:

I’ve been beating my head against a wall for hours over something which should be simple (or so I read). I’m trying to get FreeRTOS 5.0.2 running on my Olimex SAM7-P256 board using CrossWorks and an Olimex USB JTAG interface. I’m working with the lwIP_Demo_Rowley_ARM7 demo project because this appears to be the closest match for my system. I’ve ripped out the IwIP stuff and Ethernet stuff from the project because my AT91SAM7S lacks the Ethernet port that the AT91SAM7X has. The code compiles and links without error. My understanding is that these two chips are essentially identical (from FreeRTOS’s point of view) except for the Ethernet port, so I should be able to use this project for my board. Yes, I may have to change some pin assignments if I want the buttons and LEDs to work, but for starters I’m just trying to get the code to run at all.

The failure occurs after the compiled code is downloaded to the board. I am told that the verification of the downloaded code fails.

Now, the obvious conclusion is that there’s something wrong with my JTAG or my board, but I have no trouble building and running other code with the same system. For instance I can build and run the CrossWorks examples without any fuss. I have also successfully built, dowloaded and executed the ARM7_LPC2138_Rowley demo using the same installation of CrossWorks, the same JTAG interface, and an Olimex LPC-P2106 board, after changing the target processor type appropriately.

So, my questions are:
1) is anyone else using FreeRTOS on this board with the CrossWorks dev tools?
2) might anyone have any ideas why I can’t get this particular project to run?

Thanks in advance for any help anyone can offer. It’s probably worth mentioning that I’m quite experienced with software development in general, fairly experienced with writing code for the ATmega128, and quite new to the ARM world.

edwards3 wrote on Thursday, July 03, 2008:

So it is actually programming the flash memory with the binary that fails.

You are using an S256 device and from what you say this has the same flash memory and memory map as the X256 device, so it looks like it is not a linker file issue. Unless the loader is using the Ethernet RAM which is not very likely at all.

How does the USB JTAG program the flash?  OpenOCD requires the correct configuration to know how to access the flash, is the USB JTAG using a similar scheme. Could it just be a configuration problem?

You could try using SAM-BA to program the flash, then attach to the program from cross works. Should work to get you up and running but not a real solution.

studionebula wrote on Thursday, July 03, 2008:

Right. It’s the programming of the Flash that’s failing.

I think–and I’m not entirely sure of this, so it would be worth checking–that the configuration for the USB JTAG is stored independently of the project by CrossWorks. I am able to program the Flash on the same board with other projects. Also, since I am able to program a different board with the same JTAG, I think that it is not the JTAG or its configuration.

So I think the next thing I need to do is confirm that the X256 and S256 devices have the same memory map. I thought I read something somewhere in the FreeRTOS site that suggested this, but maybe I was mistaken. In any case it’s obviously something I should look into.

studionebula wrote on Thursday, July 03, 2008:

Okay, I just read the two Atmel references and it looks to me that these chips have the same memory map–or rather, they map their Flash and SRAM to the same addresses. So I now think that’s not the problem.

The next thing I’ll do is microscopically examine the project settings, comparing a working project to the FreeRTOS project settings. Unfortunately this is difficult because CrossWorks does not allow multiple instances or opening multiple projects.

rlagace wrote on Friday, July 04, 2008:


You can enable multiple instance of Crossworks. Go to Tools/Options/Environment/Startup Options/Allow Multiple CrossStudios and put that feature to yes.

Hope that it will help you.

studionebula wrote on Friday, July 04, 2008:

Thanks for that tip. I guess I should have checked the docs for this option. :-/

I suppose it makes sense to not allow multiple instances by default, since it could cause contention for the debugger hardware.

studionebula wrote on Friday, July 04, 2008:

I finally figured it out. The Target Options in the CrossWorks project file included with the FreeRTOS demo are wrong. These fields are empty:

Loader File Path
Loader Parameter
Reset Script

I copied the following values from a CrossWorks example project, and now I can successfully run the FreeRTOS demo:

Loader File Path: $(StudioDir)/targets/Atmel_AT91SAM7/Release/Loader.elf
Loader Parameter: 18432000
Reset Script: FLASHReset()

I don’t know whether all of these settings are necessary but I’m fairly certain that the first one is essential, since it seems to tell CrossWorks how to load the code into the board.