rtel wrote on Wednesday, August 03, 2005:
Unfortunately a business trip, not a vacation. 
nobody wrote on Monday, August 08, 2005:
Here is the update on where I am:
I was able to flash my code into Flash and run it. It worked fine - i.e. the led starts flashing at regular intervals as expected.
For this to work, I had to do the following:
MEMORY
{
flash : ORIGIN = 0x00000000, LENGTH = 64K
ram : ORIGIN = 0x00300000, LENGTH = 128K
}
__stack_end__ = 0x00300000 + 128K - 4;
What is not clear to me is :
Since the boot.s does not do any re-mapping, RAM that is available on power on at 0x00300000 is only 8K where as the linker file assumes it to be 128K.
Do you have any ideas on this??
Now getting back to running it from RAM,
I have tried various combinations of memory mapping and the only one that PARTIALLY works is:
MEMORY
{
sram : org = 0x00200000, len = 512K /* 512KBytes of SRAM */
}
__stack_end__ = 0x02000000 +5128K - 4;
This flashes the LED 4 times (as programmed) but then stops asoon as the OS is started.
I have tried using the secondary RAM bank statring at 0x00100000 but it would not even load the code there?
Setting the memory at 0x000000000 did not work either.
Any suggestions?
Regards,
B
nobody wrote on Tuesday, August 09, 2005:
Can you remap using the JTAG. Some JTAGs have scripts that can peek and poke before and after download. This way you can remap before the code runs, and therefore run it directly from RAM at the start.
I suspect the problem of the LED’s running but stopping when the scheduler starts is due to incorrect mapping of the IRQ vector. The code runns fine from RAM, but when the scheduler starts the tick interrupt is causing a vector to an incorrect address.
You can manually copy the vectors into the correct place. Look at the position and size in RAM of the vectors, then copy them into the correct place following the remap.
nobody wrote on Tuesday, August 09, 2005:
Interrupt vector seems to be OK. I did the following experiment:
I added a dummy variable xTickCount1 in the vTaskIncrementTick() function to see if the interrupt was being invoked.
I put two break points in the code:
One in main routine, where I call the vTaskDelay(…)
and one in the tasks.c at the end of the vTaskIncrementTick().
inline void vTaskIncrementTick( void )
{
/* Called by the portable layer each time a tick interrupt occurs.
Increments the tick then checks to see if the new tick value will cause any
tasks to be unblocked. */
if( uxSchedulerSuspended == ( unsigned portBASE_TYPE ) pdFALSE )
{
++xTickCount;
++xTickCount1;//bs
if( xTickCount == ( portTickType ) 0 )
{
volatile xList *pxTemp;
/* Tick count has overflowed so we need to swap the delay lists. If there are
any items in pxDelayedTaskList here then there is an error! */
pxTemp = pxDelayedTaskList;
pxDelayedTaskList = pxOverflowDelayedTaskList;
pxOverflowDelayedTaskList = pxTemp;
}
/* See if this tick has made a timeout expire. */
prvCheckDelayedTasks();
}
else
{
++xTickCount1;//bs
++uxMissedTicks;
}
} //Added break point at the line number corresponding to this statement.
Second break point was added as:
break tasks.c:lineNumber if xTickCount1 > 20
i.e. the routine has been hit 20 times.
The program does break at this point and the value is 21.
Another observation:
If I remove the breakpoint in main, then it does not hit this break point either.
Any other ideas?
Desparately trying to get out of this to make some progress with the actual project.
Thank you for your time.
Regards,
b
nobody wrote on Wednesday, August 10, 2005:
Are you able to send Richard the code? He is normally quite good at taking a look for people to see if anything can be found?
nobody wrote on Wednesday, August 10, 2005:
He is helping but he is out on a business trip.
I don’t think there is any issue with the code. I believe the issue is with the linker file. There are some difference in the available memory between AT91R40807 processor (which I have on my board) and the AT9140008 for which the code has been tested.
Any and all ideas are welcome as long as I can try it with my setup.
Regards,
B