FreeRTOS on AT91SAM7A3

Kernel
1

eavg wrote on Tuesday, February 24, 2009:

HI :slight_smile:

I’ve created a FreeRTOS project for the AT91SAM7A3 based on the AT91SAM7S64.
It now compiles and downloads but when I start single stepping through the code the first 4 statements of the Cstartup.s file:

   ldr     r13,=TOP_OF_MEMORY
   ldr     r0,=AT91F_LowLevelInit
   mov     lr, pc
   bx      r0

are visualised and executed by the IAR debugger as:

  BIC    R0, R0, #0x300
  MOV    R1, #0x4
  STR    R1, [R0, #+0]
  BX    LR

could anyone state a reason for this?

thanks

2

davedoors wrote on Wednesday, February 25, 2009:

Are you running from RAM or flash?

Check the script that the debugger runs (.mac?) when it starts up. It might be performing a remap operation so the vector table is moved.

Also check the linker script is correct for that device.

3

eavg wrote on Wednesday, February 25, 2009:

The problem seems to be in fact related with the vector table.
The vector table is not being placed at 0x00100000, instead it ends up at 0x00101490.

In the .icf file there is a definition:
define symbol __ICFEDIT_intvec_start__ = 0x00000000;

but somehow this definition does not seemed to produce any result.

would there be anyother way like a good old ORG to place the vector table at 0x00100000?

4

eavg wrote on Wednesday, February 25, 2009:

I’ve noticed that the original project uses Thumb mode instead of ARM.
When this option is changed the code generated for the vector table is then placed at the right address.

Why Thumb mode?

5

rtel wrote on Wednesday, February 25, 2009:

The SAM7 will run both ARM and THUMB code - but is optimised to run THUMB as it has 16bit internal interfaces.

Regards.

6

eavg wrote on Thursday, February 26, 2009:

I’ve noticed that the original project uses Thumb mode instead of ARM.
When this option is changed the code generated for the vector table is then placed at the right address.

Why Thumb mode?

7

eavg wrote on Thursday, February 26, 2009:

Just for my knowledge what would be the reason for the vector table to be placed in no man’s land when the processor mode selected was ARM?
The Cstartup.s must use ARM mode since an ARM statement is at the begin.

Now, I’m experiencing a different behaviour. I can compile/download but when it is time to pu breakpoints IAR refuses to do so, just emits a sound!!!
By using J-Link Control Panel I verify that I already have a breakpoint at iar_semihosting and a Watchpoint at 0x8000000, but I don’t seem to be capable to delete them.

Help! :slight_smile:

thanks

8

davedoors wrote on Thursday, February 26, 2009:

Make sure your project is not trying to do semihosting via the SWI interrupt as this won’t work with FreeRTOS.

9

eavg wrote on Thursday, February 26, 2009:

Hi :slight_smile:

At the moment I’m able to run until the call vPortStartFirstTask in the function xPortStartScheduler in the file port.c.

Once I made the call it falls apart.
I’m not able to put any breakpoint in portSAVE_CONTEXT in ISR_Support.h to see exactly what happens.

Once I break the debugger it is somewhere between address 8h to 24h.

any ideas?

10

edwards3 wrote on Thursday, February 26, 2009:

Are you in Supervisor mode when main() is called? You need to be.

11

eavg wrote on Friday, February 27, 2009:

When the program gets into main:

CPSR MODE is 10011 (Supervisor)
and the processor is in Thumb mode.

althought all five SPSR indicate the MODE as 10000 (User)!!!

12

eavg wrote on Friday, February 27, 2009:

I’m able to follow till this point in tasks.c (line 676)

/* Force a reschedule if xTaskResumeAll has not already done so, we may have put ourselves to sleep. */

if( !xAlreadyYielded )
{
  taskYIELD();
}

this call to taskYIELD() is disasemblied as:

SWI 0

as defined in portmacro.h

The result of single-step this call taskYIELD() is that the PC is at address 14h on ARM mode.

What I should see is the swi handler being called as defined in Cstartup.s

__swi_handler:
        ldr  pc,[pc,#+24]             ;; Software interrupt (SWI/SVC)

which in turn should use

        DC32  vPortYieldProcessor

and end-up in vPortYieldProcessor in portasm.s79.

shouldn’t this file portasm.s79 be in ARM mode? I don’t see the RARM directive.

13

davedoors wrote on Friday, February 27, 2009:

Yes it should be in ARM mode but I think it will be anyway. When you look at the disassembly is there an instruction every 4 bytes or every 2 bytes?

It looks like the SWI handler is working. Is is correctly jumping to vPortYieldProcessor().

14

eavg wrote on Friday, February 27, 2009:

at address 14h is 4 bytes but at address 20h becomes 2 bytes.
(but the instructions are somehow strange! (ARM/Thumb issue!!!???))

This is the code:
14h BC08469C STCLT p6, C4, [R8], {156}
18h 46C04760 STRMIB R4, [R0], +R0, ROR #14
1Ch 00100968 ANDEQS R0, R0, R8, ROR #18
20h B5FF PUSH {R0,R1,R2.R3,R4,R5,R6,R7,LR}
22h B081 SUB SP, SP, #4

15

johst wrote on Monday, March 02, 2009:

After all, I still have the problem with the vector table.
I thought that the vector table was being placed at the right address but it isn’t!!!

The vector table is not being placed at 0x00100000, instead it ends up at 0x00101040.

In the .icf file there is a definition:
  define symbol __ICFEDIT_intvec_start__ = 0x00000000;
but somehow this definition does not seem to produce any result.

In this way when the instruction SWI is executed the processor starts running the wrong code.
(Nevertheless, IAR is able to start the program properly!!!!)

How do I place the vector table at 0x00100000, please?

/Johan on behalf of eavg