HI :)

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:

BICR0, R0, #0x300
MOVR1, #0x4
STRR1, [R0, #+0]
BXLR

could anyone state a reason for this?

thanks

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.

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?

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?

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

Regards.

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?

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! :)

thanks

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

Hi :)

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?

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

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)!!!

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.

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().

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

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