0

Xmega port for students

Yuriy

June 03, 2011 18:14

None

Follow

Hi everybody!

I have started a project on github, which involves porting all the drivers from Atmel's framework to xmega. It is intended to help students to kick-off with their projects. Compiles with GCC in AVR Studio or Eclipse with AVR Plugin (I like it better :-).

So far I have a working kernel (thanks to the guys on this forum), which automatically adjusts to program counter size according to the device defined.

Currently this port was tested with FreeRTOS 7.0.2 on 128A1, 128A3, 192D3, 64D3, XPlain boards and many others.

For those, who want some DIY, there are schematics for EAGLE (free version) available for development boards. Boards themselves are available for purchase at manufacturing costs (I get no profit, it is for fun). You will have to solder them yourselves:-)

Since all XMEGA devices offer compatibly within the family, it seems to me that this project will be of some use for everyone.

Everybody is welcome to take part:

https://github.com/yuriykulikov/FreeRTOS_on_xmega

Best wishes,

Yuriy

• Facebook
• Twitter
• LinkedIn

34 comments

• 0
  
  Yuriy June 05, 2011 11:41

  I have made some bug fixes in the example uart task.

• 0
  
  Yuriy September 25, 2011 14:11

  Port is further developed.

  Tested on several boards, including XPLAIN.

  Recent updates: Kernel source updated to FreeRTOS 7.0.2. Command Interpreter Util for the FreeRTOS 7.0.2. is used.

  Spi drivers for master and slave are now included.

  Cheers,

  Yuriy

• 0
  
  Yuriy April 02, 2012 15:32

  Hi all,

  for those who is interested, project has moved to

  https://github.com/yuriykulikov/FreeRTOS_on_xmega

  and related project:

  https://github.com/yuriykulikov/FreeRTOS_on_xmega

• 0
  
  Samuel W. May 08, 2012 15:50

  Hi Yuri,

   

  I noticed in your port that the code to save to RAMP and EIND registers is commented out.  What is the reason for this?  It seems like for devices with > 64k these must be saved.

   

  Thanks,

  Sam

• 0
  
  Yuriy May 08, 2012 22:36

  Hi Sam,

  yes you are almost right. These regs should be saved if you address > 64k. My last build is 33278 bytes ROM and 5526 bytes RAM. To be honest I cannot recall why I have commented out these operations (it was done before I have started to you git and now I don't have any record why it was done). Maybe I wanted to speed up context switch. You can try to uncomment them if you think this should be done. RAMPZ should be saved for sure if you are accessing FLASH memory from multiple threads. I would appreciate if you can submit a patch which works for you.

  
  

  Cheers,

  Yuriy

• 0
  
  Samuel W. May 09, 2012 14:20

  Here is what I have done so far.
  I modified the linker script (avrxmega7.x) as follows:
  ...
  text (rx) : ORIGIN = 0, LENGTH = 1024K
  highmem (rx) : ORIGIN = 65536, LENGTH = 64K
  data (rw!x) : ORIGIN = 0x802000, LENGTH = 0xffa0
  ...
  } > data
  .highmem :
  {
  *(.highmem)
  } > highmem
  .bss : AT (ADDR (.bss))
  ...

  I created three tasks:

  void vIdleTask( void * pvParameters );
  // Flash low nibble on PORTE (LEDS on Xplain)
  void vFlashLowTask( void * pvParameters );
  // Flash high nibble on PORTE (LEDS on Xplain)
  void vFlashHighTask( void * pvParameters ); //__attribute__((section (".highmem")));

  I uncommented the appropriate code in port.c
  At first it did not work then I made the following changes:
  *pxTopOfStack = ( portSTACK_TYPE ) 0x38; /* 38 RAMPD */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x39; /* 39 RAMPX */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x3a; /* 3a RAMPY */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x3b; /* 3b RAMPZ */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x3c; /* 3c EIND */
  pxTopOfStack--;

  *pxTopOfStack = ( portSTACK_TYPE ) 0x00; /* 38 RAMPD */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x00; /* 39 RAMPX */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x00; /* 3a RAMPY */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x00; /* 3b RAMPZ */
  pxTopOfStack--;
  *pxTopOfStack = ( portSTACK_TYPE ) 0x00; /* 3c EIND */
  pxTopOfStack--;
  
  
  It started working!!! Great I thought, so I moved vFlashHighTask to .highmem:
  void vFlashHighTask( void * pvParameters ) __attribute__((section (".highmem")));

  And it failed. I believe this is because EIND is not initialized correctly in pxPortInitialiseStack (I think it should be 0x01 for vFlashHighTask, 0x00 otherwise).
  I am not exactly sure how to determine what the initial value of the RAMP and EIND registers should be in pxPortInitialiseStack. Does anyone have any ideas?
  Until this gets solved all the xmegas will be limited to 64kB address space.

• 0
  
  Yuriy May 09, 2012 14:52

  I have just loked up some old code for ATMEGA2560, for which I had a port as well, and I am pretty sure I was using flash memory above 128K, at least for bitmaps. Saving RAMPZ was reuired for that. EIND, as far as I know, is used to access SRAM above 64K. It was saved as well in that port. RAMPD, X and Y were not saved. Values you put in *pxPortInitialiseStack should not matter.

  I will look into it on the weekend, if you can provide some instructions how can I put a function into the highmem using eclipse and gcc compiler.

• 0
  
  Samuel W. May 09, 2012 14:54

  Hrmmm, interesting.  I thought about initializing the EIND register based on pxCode in pxPortInitialiseStack:

  *pxTopOfStack = ( portSTACK_TYPE ) (pxCode >> 16); /* 3c EIND */
  pxTopOfStack--;

  But pxCode does not seem to be the correct value...  

  Here is avr-objdump -d for vFlashHighTask:

  00010000 <vFlashHighTask>:
  10000: 1f 93 push r17
  10002: cf 93 push r28
  10004: df 93 push r29
  10006: c0 e8 ldi r28, 0x80 ; 128
  10008: d6 e0 ldi r29, 0x06 ; 6
  1000a: 10 ef ldi r17, 0xF0 ; 240
  1000c: 1f 83 std Y+7, r17 ; 0x07
  1000e: 8a ef ldi r24, 0xFA ; 250
  10010: 90 e0 ldi r25, 0x00 ; 0
  10012: 0e 94 ed 0f call 0x1fda ; 0x1fda <vTaskDelay>
  10016: fa cf rjmp .-12 ; 0x1000c <vFlashHighTask+0xc>

  Here is the value I get for pxCode when I break with the debugger:

  + pxCode 0x8000 pdTASK_CODE{registers}@ R23 R22

   

  0x8000?  Hrmph..   I think I am close, but I am missing something.

• 0
  
  Yuriy May 09, 2012 14:59

  Oops, I got it wrong - EIND is an extended indirect register. And RAMPZ you need for accessing data stored in program memory (with strcpy_P for example).

• 0
  
  Samuel W. May 09, 2012 20:47

  Hi Yuriy,

  Sorry!  I didn't have a firm understanding on what the RAMP/EIND registers were for.   I understand more clearly now

  Here is the test project I am working with.  I have made several changes to port.c.

  To compile it go to the debug directory and type make (sorry, I am terrible at Makefiles so I just hacked the output of avr studio)

  Phew, I am burning myself out on this!

   

  sam

• 0
  
  Samuel W. May 10, 2012 15:22

  Well I think I found the problem and it has nothing to do with the stack, EIND, or the RAMP registers....

  usAddress = (uint32_t) pxCode;

  In this line of code (from pxPortInitialiseStack) pxCode is 0x8000 (the task at flash address 0x10000).   I am not exactly sure why, but it seems like there is some sign extension going on and usAddress evaluates to 0xffff8000.   So when the stack unwinds the program counter becomes 0xFF8000 not 0x008000

  
  

  hrmmm...  

• 0
  
  Richard Barry May 10, 2012 15:30

  Could it be that you are attempting to store a 32 bit value in a 16 bit address?  Or that you need an extra byte to store the its used for the extended addressing?

• 0
  
  Samuel W. May 10, 2012 15:34

  Yuck!  I think I found something even worse:

  typedef void (*pdTASK_CODE)( void * );   //projdefs.h

  sizeof(pdTASK_CODE) == 2

   

  So basically this must mean that you can only have tasks in first 128kB of flash (seeing the least sig. bit is dropped from the PC).   Ok, maybe I over-reacted.  This isn't so terrible... you just need to be careful that your tasks start below 128k.

   

  Sam

• 0
  
  Samuel W. May 10, 2012 15:44

  Hi Richard. 

  This size of pdTASK_CODE is 16 bit.  Obviously you know that this is a function pointer :).  

  usAddress = (uint32_t) pxCode;  

  It seems like I (actually Yuriy) is storing a 16 bit value into an unsigned 32 bit integer.   This almost stinks of a compiler bug to me...  but I do not have much, if any, experience casting functions pointers to integers.

   

• 0
  
  Richard Barry May 10, 2012 15:46

  I'm not sure how you are concluding what you are concluding.  The line you object to defines a type that is a function pointer, the function pointer type being defined by the compiler.  I have seen compilers for extended 8/16 bit architectures (I forget which) where the size of a pointer is less than the memory range of the MCU (because the program counter spans more than one register and a pointer is held in a single register) and in those cases the pointer actually points to a jump table that contains the true address.

  I don't know if that is relevant in this case, but the point is, the line of code is just a pointer type and the compiler must be able to handle it otherwise you would not be able to use pointers in standard C functions.

• 0
  
  Samuel W. May 10, 2012 15:49

  usAddress = (uint32_t)((uint16_t)pxCode);

  This seems to fix it.  I now have tasks running in an address above 64k.

  I am still limited to keeping tasks below 128k but this is a compiler problem, nothing to do with FreeRTOS or the port.   I could probably get around that issue by passing the address of task (as a uint32_t) as the first parameter in each task struct and adjust pxPortInitialiseStack accordingly.  

  
  

  Yuriy, I will post a patch shortly once I clean things up a bit.

• 0
  
  Richard Barry May 10, 2012 15:56

  Looking at the MSP430X port layer could possible (?) help.  It has similar issues, and contains code such as:

   

  /* portSTACK_TYPE is either 16 bits or 32 bits depending on the data model.
  Some stacked items do not change size depending on the data model so have
  to be explicitly cast to the correct size so this function will work
  whichever data model is being used. */
  if( sizeof( portSTACK_TYPE ) == sizeof( unsigned short ) )
  {
  /* Make room for a 20 bit value stored as a 32 bit value. */
  pusTopOfStack = ( unsigned short * ) pxTopOfStack;
  pusTopOfStack--;
  pulTopOfStack = ( unsigned long * ) pusTopOfStack;
  }
  else
  {
  pulTopOfStack = ( unsigned long * ) pxTopOfStack;
  }
  *pulTopOfStack = ( unsigned long ) pxCode;

• 0
  
  Samuel W. May 10, 2012 16:02

  Hi Richard,

  There may have been a misunderstanding.  I don't think the fact that size of a function pointer is not large enough to cover the entire address space is a bug (or even a huge problem really).  More of an annoyance really.   I overreacted, mostly because I was getting frustrated.

  This is what I think may be a compiler bug:

  pxCode is a 16 bit function pointer with a value of 0x8000.   When casting pxCode to an unsigned 32 bit integer it sign extends the value to 0xFFFF8000.  I could be completely wrong about this being a bug.  My understanding of casting a signed value to an unsigned value may be wrong, but I have never seen an unsigned cast sign extend like that before.

   

  Sam

• 0
  
  Yuriy May 10, 2012 16:12

  I think it is not a big deal to keep task code in the first 128K of flash, is it? More important that calls to functions which reside in a .highmem section work ok. This includes situations when the second task can corrupt EIND before the first one executes EICALL.

  Program counter on XMEGA is 24 bits or 16 bits (depending on the model), that is why I have to do

  usAddress = (uint32_t) pxCode;

  Later first three bytes (two bytes for models with 2-byte PC) of usAddress are pushed to the stack of the task. The task to which this stack belongs is in the blocked state, which is like it was preemted. When scheduler resumes the task  and instruction "ret" is executed, 3 bytes are taken from stack, which should contain return address. Since for extended indirect calls we use additional EIND register and EICALL instruction, pxCode is actually just 2 bytes. SO when I do a cast from it to a uint32_t I get last two bytes filled with zeros.

  Here is some more info:

  http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=68911&start=0

  To conclude, I believe it is better to tell the linker to keep task body functions in first 128K of flash. The rest of the flash can be used to store strings and other code (large functions). When I have some time I will investigate how indirect jumps and access to data stored in program memory work. I assume this will include saving RAMPx and EIND as parts of the context - at least it worked on atmega2560.

• 0
  
  Samuel W. May 10, 2012 16:49

  Hi Yuriy. 

   

  No, I don't think limiting tasks to the first 128k is too much of a problem.  If someone REALLY needed to they could:

  struct taskParameters {

      uint32_t funcAddr;

      ...

     ...

  };

   

  struct taskParameters;

  taskParameters.funcAddr = (uint32_t)&taskFunc;

   

  and modify the pxPortInitialiseStack to initialize the 24bit program counter using the first argument of parameter structure.  This may not be ideal, but I think it would work...  I could always test it and let you know.   There may be a more elegant way involving a array of task addresses....  I am not too concerned about it.

   

  I haven't tested this yet, but I think it is the fix:

   

  uint16_t usAddress;

  usAddress = (uint16_t)pxCode;
  
  *pxTopOfStack = (portSTACK_TYPE ) (usAddress & (uint16_t) 0x00ff);
  pxTopOfStack--;
  usAddress >>= 8;

  *pxTopOfStack = (portSTACK_TYPE ) (usAddress & (uint16_t) 0x00ff);
  pxTopOfStack--;
  
  /* If the sizeof(PC) == 3 then Flash > 128k.
  Unfortunately sizeof(pxCode) == 2, therefore
  addresses above 128k (PC is even 2-Byte aligned)
  can not be passed to this function. Setting the
  MSB of the PC to 0 limits the task address to
  below 128k. Sorry.*/
  #ifdef PROGRAMCOUNTER_24BIT
  *pxTopOfStack = (portSTACK_TYPE ) 0x00;
  pxTopOfStack--;
  #endif

• 0
  
  Yuriy May 10, 2012 16:58

  Sounds great. You can as well replace #ifdef PROGRAMCOUNTER_24BIT with  #if __AVR_3_BYTE_PC__ and remove the stuff on top related to PROGRAMCOUNTER_24BIT

  
  

  Take a look at the attached files (port.c) this is what I have found on the internet - port of FreeRTOS to mega2560 from stu, which is pretty similar to what I have had.

• 0
  
  Yuriy May 10, 2012 17:03

  I can make a commit with changes proposed by you and saving EIND and RAMPZ and put it on github tomorrow.

• 0
  
  Samuel W. May 10, 2012 18:42

  Hi Yuriy.  

  I branched your project on github...  here is my fix.  

  https://github.com/swinchen/FreeRTOS_on_xmega/tree/fix

  I am sorry the layout has changed so radically, but for testing (and my needs) things were quite different.   I have verified this code on an Xplain.  Three tasks run correctly, one of them being located at address 0x10000

  I am going to attempt a workaround for tasks above 128k.   My first attempt failed because I didn't realize that FreeRTOS started it's own tasks...  but I have an idea.  If I can get it to work I will let you know.   

   

  thanks again for porting!  

• 0
  
  Yuriy May 10, 2012 21:54

  Hi Sam,

  thank you for your effort. I will integrate changes you have made to port.c into my project.

  I see you didn't want to use C++ drivers :-) Maybe you can take same drivers but written in C from here: https://github.com/yuriykulikov/FreeRTOS-on-XMEGA-deprecated/tree/develop_c

  I was going to port everything I have now to C, but I don't have enough time.

  Cheers,

  Yuriy

• 0
  
  Samuel W. May 11, 2012 14:19

  Hi Yuriy,

  It isn't that I didn't want to use the C++ drivers.  I didn't know where to find "RxBuffer.h" and "TxBuffer.h" so I couldn't get them to compile.   I decided to strip the project down to it's bare minimum to test the kernel.  

   

  I think if people want to have tasks above 128k will have to use a trampoline (a function that resides in lower flash calling a function in higher flash).   The only method I can find to get the address of a function above 128k is to modify the linker script and output each task in it's own section.  I think the cost of this is well beyond the benefit.  I really wish the size of a function pointer in avr-gcc was 4 bytes because I am using a 256A3.  I am not going to worry about it too much because my application isn't even close to the 128k mark yet.

   

  I will take a look at the C drivers.  Thanks for the link.

   

  Sam

   

• 0
  
  Yuriy May 11, 2012 14:33

  Hi,

  For RxBuffer and TxBuffer see https://github.com/yuriykulikov/Message-Handler-Framework-for-FreeRTOS

  In the same place you can see Thread.cpp, in which there is a function taskBody(), which can be used as a trampoline.

• 0
  
  Amit Rana November 14, 2013 07:09

  Hello Yuriy,

  thank you for such a nice collection. Can I have a working demo project created using Atmel Studio 5 / Studio 6.  I am using atxmega128a4u for my new project and was not getting on How to create a project using these files listed here on this project. Can you please suggest anything

• 0
  
  Yuriy November 17, 2013 19:34

  Hi,

  thanks for your interest in my project. I tend to have many little repositories and sometimes it is hard to find out which 4 repositories you have to clone to make things running :-)

   

  Here is my latest project, which works fine in my car so far:

  https://github.com/yuriykulikov/FordMediaJoystickOverBt

  you need this littel framework as well:

  https://github.com/yuriykulikov/EventDrivenEmbeddedFramework

  and the port of FreeRTOS:

  https://github.com/yuriykulikov/FreeRTOS-on-XMEGA

   

  FreeRTOS itself you can get from http://www.freertos.org. I have tested with version 7.0.6, but it must be backward compatible.

   

  Good luck and happy hacking!

• 0
  
  Yuriy November 17, 2013 19:41

  Hey everyone and moderators :-)

   

  During last 3 years there been some interest in this project both here, on github and just over email. I have learned that 100% of the people are only intereseted in the FreeRTOS port itself and not in the drivers, events, C++ port  or whatever else. To make the thread more concentrated on porting FreeRTOS on xmega, I would like to ask moderators to clean up the thread a little. Please remove my messages related to EventDrivenEmbeddedFramework and stuff like that :-) Thanks!

• 0
  
  Amit Rana November 18, 2013 03:37

  Thank you Yuriy for sending important links. I'll check all those things and try to build project using atmel studio.