IAR AVR Port

[Giovanni]

Not sure, you should verify the preprocessed output, is there an option to see it?

Giovanni

[handaza]

I figured it.

the problem was in IAR IO header file, it defines the timer 0 int. vector location as

Code: Select all

#define    TIMER0_COMP_vect     (0x28)

the extra parentheses"()" was the problem, so I redefined it in my board.c file like this

Code: Select all

 #define    TIMER0_COMP_vector     0x28

and it works fine, thanks for your support.

now chcore.h and chcore.c are finished, borad.c still needs the HAL to be consistent with all the files.
should I make complete implementation for HAR to IAR AVR or update the current HAL to be common between the two compilers?


also I like to contribute my work bake, how can I send these files? and should I send what I finished now or wait till I finish the HAL?

[Giovanni]

Hi,

The main problem now is to make a common HAL between the two compilers, it is how other platforms do it, there is no compiler differentiation in the platforms directory, it does not look simple in this case. You could create an AVR_IAR HAL but then there would be two HALs to maintain.

For code contribution, make a zip file and open a post in the contributions forum when it is ready, it is a parking area.

Giovanni

[alexblack]

Hi.
I want to make a port on xMega device using IAR compiler. There is only this topic where IAR port for AVR was discussed.

also I like to contribute my work bake, how can I send these files? and should I send what I finished now or wait till I finish the HAL?

Can I see your results of work?

[alexblack]

Hi.
I was made ChibiOS port to support xMEGA AVR on IAR compiler.
Also I ported SERIAL driver to view results.
But when i run the TEST, the program is halted on 'Test case 11.1.'
I have no hardware debugger for this board and I can't see what happens. May I need to port somethings else?

Code: Select all

MAIN: > *** ROBOT-X V.1.00 14/03/2013***
MAIN: > CPU is AVR atXMega128A1, XTAL = 32MHz
MAIN: > Compiled Mar 14 2013 21:55:51
MAIN: > ChibiOS Version: 2.5.2

*** ChibiOS/RT test suite
***
*** Kernel:       2.5.2unstable
*** Compiled:     Mar 14 2013 - 21:56:13
*** Compiler:     IAR C/C++ Compiler V6.11.1.50453 for Atmel AVR
*** Architecture: AVR
*** Core Variant: xMegaAVR
*** Port Info:    IAR XMEGA by ALEX BLACK
*** Platform:     XMEGA
*** Test Board:   PHOTOROBOT-X

----------------------------------------------------------------------------
--- Test Case 1.1 (Threads, enqueuing test #1)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.2 (Threads, enqueuing test #2)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.3 (Threads, priority change)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.4 (Threads, delays)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.1 (Semaphores, enqueuing)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.2 (Semaphores, timeout)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.3 (Semaphores, atomic signal-wait)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.4 (Binary Semaphores, functionality)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.1 (Mutexes, priority enqueuing test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.2 (Mutexes, priority return)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.3 (Mutexes, status)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.4 (CondVar, signal test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.5 (CondVar, broadcast test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.6 (CondVar, boost test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.1 (Messages, loop)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 5.1 (Mailboxes, queuing and timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.1 (Events, registration and dispatch)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.2 (Events, wait and broadcast)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.3 (Events, timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.1 (Queues, input queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.2 (Queues, output queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.1 (Benchmark, messages #1)



[Giovanni]

Too little info for a "remote debug"

Probably it is about the definition of the intctx and extctx structures and related code.

Giovanni

[alexblack]

Hi.
I thought that if the test report 'SUCCESSFUL', it means that the function 'PORT SWITCH' okay.
When porting I guiding IAR documentation 'EWAVR_CompilerRefernce.pdf':

Code: Select all

 Scratch registers
Any function is permitted to destroy the contents of a scratch register. If a function needs the register value after a call to another function, it must store it during the call, for example on the stack. For both calling conventions, these 14 registers can be used as scratch registers by a function:
R0-R3, R16-R23, and R30-R31


Code: Select all

Preserved registers
Preserved registers, on the other hand, are preserved across function calls. The called function can use the register for other purposes, but must save the value before using the register and restore it at the exit of the function. For both calling conventions, these registers are preserved registers:
R4-R15 and R24-R27


Code: Select all

Special registers
For some registers, you must consider certain prerequisites:
● The stack pointer—register Y—must at all times point to the last element on the stack. In the eventuality of an interrupt, everything below the point the stack pointer points to, will be destroyed.
● If using the -v4 or -v6 processor option, the RAMPY register is part of the data stack pointer.
● If using a processor option which uses any of the registers EIND, RAMPX, or RAMPZ, these registers are treated as scratch registers.


Code: Select all

Register parameters
For both calling conventions, the registers available for passing parameters are:
R16–R23


Code: Select all

Interrupt functions
Interrupt functions differ from ordinary C functions in that:
● Calls to interrupt functions are made via interrupt vectors; direct calls are not allowed
● No arguments can be passed to an interrupt function
● Interrupt functions return by using the RETI function.


At this moment I decided to use RSTACK (hardware stack pointed by SP register) to save context in 'port_switch' function. Also I had to determine the common size of the RSTACK for all threads.
Unfortunately I have not found a way to force the compiler to save all registers in the interrupts, and I hoped that compiler would do it itself - maybe it's my fault?
Another assumption is to use 'LARGE' or 'HUGE' memory model, because my board have 512kB external SRAM, and to have access to it compiler must use pointers larger then 16 bit (24 bit in that situation). That's why I used +7, +8 offset in structure intctx. Using direct constants in that case very danger, because environment depended. Is there any other way to do this?
Another problem is that hardware stack can be only in internal SRAM. Because all thread's stuff allocated in one chunk there are no way to use external memory for this.
There is a problem to allocate constants in FLASH. Though provided for this special word ROMCONST, it is not widely used, where possible, and a way of definition pointers to flash in IAR requires a different approach.
And of course the last problem is to make compiler independent HAL.

[alexblack]

Hi.
I checked everything but can't find why port worked incorrectly.
I created two test threads. One is:

Code: Select all

volatile static uint32_t kkkk = 0;
static WORKING_AREA(waThread1, 32);
static msg_t Thread1(void *arg)
{
  (void) arg;
  while (TRUE)
  {
    chSysLock();
    kkkk++;
    chSysUnlock();
  }
}


The second is main:

Code: Select all

int main( void )
{
  /*
  * System initializations.
  * - HAL initialization, this also initializes the configured device drivers
  *   and performs the board-specific initializations.
  * - Kernel initialization, the main() function becomes a thread and the
  *   RTOS is active.
  */
  halInit();
  chSysInit();
         
  // Init debug serial interface
  DEBUG_INIT();
   
  /* Starts the Thread1 */
  chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO, Thread1, NULL);
   
  uint32_t i = 0;
  for (;;)
  {
    i++;
    chSysLock();
    uint32_t vk = kkkk;
    chSysUnlock();
    chprintf(dbg_port, "\ri = %lu, k = %lu ", i, vk);
  }     
}


As used round robin scheduling the debug output must contain continuously increasing values of i and kkkk (and it true if this code I run on STM32 board) but on XMEGA board 'main' thread executing only fist time and then continuously executes Thread1 (I checked this by adding some pin's activity in Thread1 and using soft emulator). if I add some pauses (chSleep) in threads, then all works OK.
I compared my port with STM32 port on IAR and it looks similar. I save all preserved registers as needed.
Also I changed port to save registers in right stack (CSTACK) - the result absolutely same.
Is anybody really run this tests on AVR, may be this is another problem ?

[Giovanni]

There is an important symptom, it crashes if you preempt a running thread, this means that the problem is in the preemption code. Probably you fail to save all the required registers in the ISRs (the extctx structure). It is very possible the problem is there also because the IAR is a different compiler and does not necessarily do things like GCC does.

The fact that it works when you insert sleeps means that probably the intctx structure is fine and thread-to-thread context switch works correctly.

Few things to check:
- ISR functions declaration.
- extctx structure.
- Registers saved in ISRs by the compiler.

In order to handle different memory model i recommend to declare the fields in intctx/extctx as pointers or function pointers like the STM8 port does. This way the size of the field will change according to the memory model.

Giovanni

[alexblack]

There is an important symptom, it crashes if you preempt a running thread, this means that the problem is in the preemption code. Probably you fail to save all the required registers in the ISRs (the extctx structure). It is very possible the problem is there also because the IAR is a different compiler and does not necessarily do things like GCC does.
Giovanni

I thought about this too. I understood how port_switch works, but can't understand how it works when preemption occurred? After all, it is happened in ISR and we must exit from it, but when change context it return in other thread, and when we return to interrupted thread and where our SREG reg is? In general it is not clear for me : (

Few things to check:
- ISR functions declaration.
- extctx structure.
- Registers saved in ISRs by the compiler.
Giovanni

I think only scheduler ISR important at this moment because regular interrupts work OK (serial driver uses 3 ISRs)? I sow compiler generated asm file and it saves all scratch registers in stack plus additional preserved registers in witch it saves I/O registers like RAMPD, SREG and others. All registers saves EXCEPT Y register, because it is used as soft stack pointer. May it require special handling in this situation? My port_switch code saves it in intctx structure.
About extctx structure - in some topic You wrote that it is used only for stack calculation size and no need to do else then compiler do... isn't it?