How do I build FreeRTOS for a different address?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again. I'm having difficulty getting my FreeRTOS application to work. It works fine as long I link the application at 80000000. The problem arises when I change the link address to an area high in flash (80020000). I have another application (not based on FreeRTOS) that loads at 80004000, and a boot loader that sits at 80000000. Those two are working fine.

I have a suspicion that this is related to the runtime library initialization code which is being linked from a pre-compiled object file, "crt0.o". In my other application at 80004000 (NOT FreeRTOS-based), there is a comment in the "Startup-UC3.S" file which states the following: "_stext is placed outside the .reset section so that the program entry point can be changed without affecting the C runtime startup." What is the significance of this statement? Also contained in that startup assembly file is code to do the basic initialization (set the stack pointer, set the EVBA, enable exceptions, and initialize data), and is labeled "_stext". This same code is NOT in the startup file in the FreeRTOS project. Rather, part of it is coming from "crt0.o", and part of it is in Port.c.

Given that background, anyone know how to build a FreeRTOS application that is linked at some address other than 80000000?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: After doing a little debugger work this morning, I’m convinced this has something to do with the initialization code either being not position-independent, or else making some (wrong) assumption about where the code is located in memory. I traced through various assembly code and eventually ended up in some code that appears to have come from “crtend.o” (based on the linker map file from my application). This code eventually loads a pointer from location 0x00000008 in RAM. The address that it loads is 0x800025FD, which is NOT in my application, but rather in my boot loader. My application starts at 0x80020000. The address is definitely not a function. It’s actually a bunch of spaces (0x20), some data in .rodata._ctype_. Needless to say, things go bad very quickly after that.

Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm running my FreeRTOS App from 0x80010000 without any problems. There's no need to change the linker script!

Just make sure, that your app's text segment get's located at your desired address. Basically you just have to adjust the define PROGRAM_START_ADDRESS in trampoline_uc3.h to your needs. Make sure that your bootloader jumps to that address.

That's it!

What's your processor type? Which bootloader did you use as a starting point? Which toolchain, linker script, etc.? More details would help to get better responses...

-sb

PS.: This might not be the right forum -> should be moved, since it's a coding issue

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Solution: Turns this was indeed caused by the standard start files. The solution has two parts. First, select “Do not use standard start files” option for the linker. Second, use Atmel’s (or your own) Startup_uc3.S startup file and modify as follows: Eliminate the trampoline-related stuff, remove initialization of the EVBA and exception processing as these are handled in the Port.c file (_init_startup). Then add a call to _init_startup before the call to main. That’s it.

This may be obvious to experienced AVR programmers, but to me it was not obvious at all that the standard startup code seems to make assumptions about how the application is structured and linked, and where it lives in memory.

To answer “sambrown”, you are right that this belongs in a different forum. And thanks for taking time to try to help. Now that I know it doesn’t have anything to do with FreeRTOS (a tool), but rather just startup code, I agree, this belongs in the coding forum. I do have to change the linker script because I don’t use Atmel’s so-called “trampoline” model. I have my own scheme. My troubles came from not fully understanding Atmel’s model, and hence deviating from it. I never understood (and still don’t) how Atmel’s startup/trampoline works. Even if you change the PROGRAM_START_OFFSET, there is still code (one instruction) that is located in the beginning of the .reset section which is at 0x80000000. This cannot be, because I have other code at that address.

Anyway, it’s working now. The folks at Atmel tech support provided the solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's well described in the following documents:
AVR32758: AVR32 UC3 USB Host Mass Storage Bootloader
and
AVR32784: 32-bit AVR UC3 USB DFU Bootloader

I like this trampoline concept since it enables you to run/debug any applications independently from each other during development.

You're right, finally you have to ensure that you flash your application and bootloader in the right order (the program that starts at 0x80000000 must be flashed last).

-sb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may also use BOOTPROT and/or Flash region lock bits.

Anyway it's worth to have a look at the above documents if you're implementing a bootloader on AVR32.

I use a script to flash my hardware since I need 3 bootloaders to be able to update my "application update bootloader" in the field, too.

-sb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Second, use Atmel’s (or your own) Startup_uc3.S startup file and modify as follows: Eliminate the trampoline-related stuff, remove initialization of the EVBA and exception processing as these are handled in the Port.c file (_init_startup). Then add a call to _init_startup before the call to main. That’s it.

Dear CDaniel_MT,

Could you publish your startup_uc3.S?
I have also my bootloader. And the problem is that the application to be flashed build some code between 0x80000000 and 0x80002000 (bootloader area).

The only solution is to manually remove this part of bytes in the hex/bin file after build.

You can see my post: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113378

Thank you,
Pierre