Hello,

• CHIP = at91sam7s64
• BOARD = at91sam7s-ek

I'm trying to use the Periodic Interval Timer from Getting Started project:

• getting-started-project-at91sam7s-ek-gnu.zip from http://www.atmel.com/dyn/resources/prod_do...t91sam7s-ek.zip

I have isolated the problem and I see that the program freezes right after enabling interrupt for PIT:

• PIT_EnableIT();

When I remove that line of code (PIT Interrupt disabled) the program runs normally.


I have checked for the correctness of the ISR handler addresss in AIC vector

• AT91C_BASE_AIC->AIC_SVR[source]

and it matches the handler address.


I don't know why the program is freezing (the program halts and the handler is not called). I also tried editing main.c to use only PIT, and only Push Button 1; in both cases the same thing happens (i.e. nothing happens, handler is not executed).


Does anyone have a clue?


Thanks in advance



PS:
Maybe I'm running the wrong address and thus ruining the start up code (which contains initial interrupt handling codes)?

In sram.lds we have the code

• sram (W!RX) : ORIGIN = 0x202000, LENGTH = 0x4000

so in SAM-BA, after loading the program, I make

• go 0x202000

Is that the correct address to go to?

Just reporting.


The board I'm using is a AT91SAM7S-EK with a AT91SAM7S64 chip. In this board, RAM is mapped at 0x200000 and there is a Remap feature that allows RAM to be accessed from 0x000000. The exception handler is located at 0x000000 (IRQ Handler lies at 0x000018).


After more than one month stuck and trying to figure out the problem (btw I have never used GNU Tools nor had any experience with ARM embedded programing), I found that the Linker Script provided by Atmel in Getting-Started-Project-GNU maps RAM at 0x202000, I don't know why. This way, the processor couldn't find the irqHandler (from C Startup assembler code) at 0x000018.


After fixing the Linker Script and after dealing hard with JTAG/Eclipse/Remote GDB I finally could use interrupt.

Hello,

I have a question about Atmel AT91SAM9261 getting-started-project (for GNU compiler) from at91sam9261 software package. I post this here because this is a pretty similar looking problem.

I am using newest YAGARTO GNU ARM toolchain and YAGARTO Tools. Also using the newest Eclipse environment.

My board is (still) Olimex SAM9-L9261 board.

With IAR Kick-Start compiler this same example program worked ok, so I know the program works with my board. And of course with IAR compiler I used IAR example and now I use the GNU example.

Symptoms with GNU:

1. everything compiles, links and obj-copies ok (both from Eclipse and command line), no debug, -Os

2. using SAM-BA I download the bin-file (it does not matter if I download sram or sdram version, it works the same)

3. start the program, e.g. go 0x20000000

4. the program writes the right texts to rs port, so I can see in HyperTerminal e.g. "Getting Started Project 1.5" and so on

5. then the program hangs and it hangs in ConfigurePit subprogram after it has written the message "Pit 5", so it hangs when it enables PIT interrupt:

//------------------------------------------------------------------------------
/// Configure the periodic interval timer to generate an interrupt every
/// millisecond.
//------------------------------------------------------------------------------
void ConfigurePit(void)
{
// Initialize the PIT to the desired frequency
PIT_Init(PIT_PERIOD, BOARD_MCK / 1000000);

// Configure interrupt on PIT
AIC_DisableIT(AT91C_ID_SYS);
AIC_ConfigureIT(AT91C_ID_SYS, AT91C_AIC_PRIOR_LOWEST, ISR_Pit);
AIC_EnableIT(AT91C_ID_SYS);
printf("Pit 5\n\r");
PIT_EnableIT();
printf("Pit 6\n\r");

// Enable the pit
PIT_Enable();
}

The subroutine where it hangs is:

//----------------------------------------------------------------------------
/// Enable the PIT periodic interrupt.
//----------------------------------------------------------------------------
void PIT_EnableIT(void)
{
AT91C_BASE_PITC->PITC_PIMR |= AT91C_PITC_PITIEN;
}

If I do not initialize interrups but only printf messages in a loop, that works fine.

6. Furuya had very similar problems with the same kind of example, but it was with different chip, SAM7 chip. The solution was then that start of RAM was first in wrong address and the irqHandler was not found.

Could it be something similar now? I do not want to struggle a month with this as was the case with Furuya.

I use the original link script that locates the ram into address as follows:

MEMORY
{
sram (W!RX) : ORIGIN = 0x300000, LENGTH = 0x28000
sdram (W!RX) : ORIGIN = 0x20000000, LENGTH = 0x4000000
}

7. I really have tried to find some solution, but with no luck. I quess there must be a pretty simple explanation (and solution) to this.

Regards Antti

Hello again,

I have found some kind of solution for this problem but still very confused.

When I stripped away optimization flag from the makefile (-Oz) the getting-started-project program surprisingly got started and also kept going. The interrupts keep interrupting and so on.

This happened with both tool chains I am experimenting now, YAGARTO and (Code)Sourcery G++ Lite for ARM EABI.

Could someone tell what is happening.

Next I need more memory for unsigned int tables where I store measurement data, hope that works without struggling for days or weeks.

Regards Antti

Hello,

some more work with this.

getting-started-program really fails to run, when I use -Os optimization (or any other global optimization, e.g. O2). In that case, all c- and asm-modules are optimized. Also linker gets -Os flag.

Anayway the reason is in c-modules because when I give separate optimization for asm-modules and linker it works.

With -Os flag it seems that when PIT IRQ handler is called the first time, it goes to Mars. If I disable PIT, it fails when TC0 IRQ handler is called first time.

But when I take the global -Os flag away and optimize (e.g. with #pragma GCC optimize ("2")) only my main.c everything goes smoothly. The IRQ handlers are in main.c module.

I have tried to find where it goes wrong with the global -Os flag but with no luck.

I think I will carry on with this #pragma strategy. It takes too much time and effort to try to find out the original reason because I am very new in ARM programming field.

Is this a common problem or do I only have very bad luck?

If anybody has any ideas to this problem please let me know.

Regards Antti

I had this same problem and was scratching my head until I found this post - so thank you for posting the resolution. Turning off the optimisations solved my issue with the getting started project hanging, so thanks!