Having received help here on getting my GNU tool chain working it is
now running like a charm.
I have however run into problems getting the "basic-rtt-project" from
Atmel at91sam7s-ek software up and running.
It compiles fine - but when I upload it to my microcontroller (ram
version) and runs it I get the initial response on my serial
connection :
-- Basic RTT Project 1.5 --
-- AT91SAM7S-EK
-- Compiled: Jun 5 2010 22:52:51 --
And then nothing... The microcontroller seems to hang.
I have tried to insert debug printf's (as I dont have a JTAG to
singlestep or debug the unit).
The result is that I have identified the line that hangs the
microcontroller.
In the main.c :
//------
/// Configures the RTT to generate a one second tick, which triggers
the RTTINC /// interrupt.
//------
void ConfigureRtt(void)
{
unsigned int previousTime;
printf("Debug point 0.1\n\r");
// Configure RTT for a 1 second tick interrupt
RTT_SetPrescaler(AT91C_BASE_RTTC, 32768);
previousTime = RTT_GetTime(AT91C_BASE_RTTC);
printf("Debug point 0.2\n\r");
while (previousTime == RTT_GetTime(AT91C_BASE_RTTC));
printf("Debug point 0.3\n\r");
// Enable RTT interrupt
AIC_ConfigureIT(AT91C_ID_SYS, 0, ISR_Rtt);
printf("Debug point 0.4\n\r");
AIC_EnableIT(AT91C_ID_SYS);
printf("Debug point 0.5\n\r");
// The line below hangs the system
RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
// This printf never gets outputted to the serialport (actually DBGU)
printf("Debug point 0.6\n\r");
}
Now... Any idea's of how to figure out what is going wrong?
Best regards
JesperKP
Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Started by ●June 5, 2010
Reply by ●June 5, 20102010-06-05
On Sun, 6 Jun 2010 01:52:44 +0200
"Jesper K. Pedersen" wrote:
> // The line below hangs the system
> RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
Just a blind guess: Enabling that interrupt is causing something to
either hang in your interrupt routine, or the hardware is pulling that
interrupt in some way that as soon as your interrupt routine it's
getting called again.
Dan
"Jesper K. Pedersen" wrote:
> // The line below hangs the system
> RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
Just a blind guess: Enabling that interrupt is causing something to
either hang in your interrupt routine, or the hardware is pulling that
interrupt in some way that as soon as your interrupt routine it's
getting called again.
Dan
Reply by ●June 6, 20102010-06-06
On Sat, 5 Jun 2010 19:35:12 -0700
Dan Lyke wrote:
> On Sun, 6 Jun 2010 01:52:44 +0200
> "Jesper K. Pedersen" wrote:
> > // The line below hangs the system
> > RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
>
> Just a blind guess: Enabling that interrupt is causing something to
> either hang in your interrupt routine, or the hardware is pulling that
> interrupt in some way that as soon as your interrupt routine it's
> getting called again.
>
I think you are right about that. As the interrupt is a 1 second
generated interrupt and the timer is reset I suspect the interrupt
is being called.
I just wonder if it is a problem with the interrupt routine. My
"challenge" is that it is a piece of software that is a
"getting-started" thing from Atmel that I havent edited anything in -
and it does not run.
The "worse" part is that the Makefile is a somewhat cumbersome one - so
it is not easy for me to add the generation of a map file showing what
functions go to which address.
Best regards
JesperKP
Dan Lyke wrote:
> On Sun, 6 Jun 2010 01:52:44 +0200
> "Jesper K. Pedersen" wrote:
> > // The line below hangs the system
> > RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
>
> Just a blind guess: Enabling that interrupt is causing something to
> either hang in your interrupt routine, or the hardware is pulling that
> interrupt in some way that as soon as your interrupt routine it's
> getting called again.
>
I think you are right about that. As the interrupt is a 1 second
generated interrupt and the timer is reset I suspect the interrupt
is being called.
I just wonder if it is a problem with the interrupt routine. My
"challenge" is that it is a piece of software that is a
"getting-started" thing from Atmel that I havent edited anything in -
and it does not run.
The "worse" part is that the Makefile is a somewhat cumbersome one - so
it is not easy for me to add the generation of a map file showing what
functions go to which address.
Best regards
JesperKP
Reply by ●June 6, 20102010-06-06
On Sun, Jun 06, 2010 at 01:49:48PM +0200, Jesper K. Pedersen wrote:
> On Sat, 5 Jun 2010 19:35:12 -0700
> Dan Lyke wrote:
>
> > On Sun, 6 Jun 2010 01:52:44 +0200
> > "Jesper K. Pedersen" wrote:
> > > // The line below hangs the system
> > > RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
> >
> > Just a blind guess: Enabling that interrupt is causing something to
> > either hang in your interrupt routine, or the hardware is pulling that
> > interrupt in some way that as soon as your interrupt routine it's
> > getting called again.
> > I think you are right about that. As the interrupt is a 1 second
> generated interrupt and the timer is reset I suspect the interrupt
> is being called.
Don't forget that the system interrupt is shared with other devices.
You might steel your OS the interrupts from e.g. system timer so
it can't timeout/schedule anymore.
--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> On Sat, 5 Jun 2010 19:35:12 -0700
> Dan Lyke wrote:
>
> > On Sun, 6 Jun 2010 01:52:44 +0200
> > "Jesper K. Pedersen" wrote:
> > > // The line below hangs the system
> > > RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
> >
> > Just a blind guess: Enabling that interrupt is causing something to
> > either hang in your interrupt routine, or the hardware is pulling that
> > interrupt in some way that as soon as your interrupt routine it's
> > getting called again.
> > I think you are right about that. As the interrupt is a 1 second
> generated interrupt and the timer is reset I suspect the interrupt
> is being called.
Don't forget that the system interrupt is shared with other devices.
You might steel your OS the interrupts from e.g. system timer so
it can't timeout/schedule anymore.
--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Reply by ●June 6, 20102010-06-06
Hi,
I have not used the the arm7s series, but I have another question, why are you using the RAM version of the compile, is there some special reason? Why dot' you just use the FLASH version of the compile and load it into the internal flash and try executing?
Rgds.
________________________________
From: Jesper K. Pedersen
To: A...
Sent: Sun, June 6, 2010 4:22:44 AM
Subject: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Having received help here on getting my GNU tool chain working it is
now running like a charm.
I have however run into problems getting the "basic-rtt-project" from
Atmel at91sam7s-ek software up and running.
It compiles fine - but when I upload it to my microcontroller (ram
version) and runs it I get the initial response on my serial
connection :
-- Basic RTT Project 1.5 --
-- AT91SAM7S-EK
-- Compiled: Jun 5 2010 22:52:51 --
And then nothing... The microcontroller seems to hang.
I have tried to insert debug printf's (as I dont have a JTAG to
singlestep or debug the unit).
The result is that I have identified the line that hangs the
microcontroller.
In the main.c :
//----------------------
/// Configures the RTT to generate a one second tick, which triggers
the RTTINC /// interrupt.
//----------------------
void ConfigureRtt(void)
{
unsigned int previousTime;
printf("Debug point 0.1\n\r");
// Configure RTT for a 1 second tick interrupt
RTT_SetPrescaler(AT91C_BASE_RTTC, 32768);
previousTime = RTT_GetTime(AT91C_BASE_RTTC);
printf("Debug point 0.2\n\r");
while (previousTime == RTT_GetTime(AT91C_BASE_RTTC));
printf("Debug point 0.3\n\r");
// Enable RTT interrupt
AIC_ConfigureIT(AT91C_ID_SYS, 0, ISR_Rtt);
printf("Debug point 0.4\n\r");
AIC_EnableIT(AT91C_ID_SYS);
printf("Debug point 0.5\n\r");
// The line below hangs the system
RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
// This printf never gets outputted to the serialport (actually DBGU)
printf("Debug point 0.6\n\r");
}
Now... Any idea's of how to figure out what is going wrong?
Best regards
JesperKP
I have not used the the arm7s series, but I have another question, why are you using the RAM version of the compile, is there some special reason? Why dot' you just use the FLASH version of the compile and load it into the internal flash and try executing?
Rgds.
________________________________
From: Jesper K. Pedersen
To: A...
Sent: Sun, June 6, 2010 4:22:44 AM
Subject: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Having received help here on getting my GNU tool chain working it is
now running like a charm.
I have however run into problems getting the "basic-rtt-project" from
Atmel at91sam7s-ek software up and running.
It compiles fine - but when I upload it to my microcontroller (ram
version) and runs it I get the initial response on my serial
connection :
-- Basic RTT Project 1.5 --
-- AT91SAM7S-EK
-- Compiled: Jun 5 2010 22:52:51 --
And then nothing... The microcontroller seems to hang.
I have tried to insert debug printf's (as I dont have a JTAG to
singlestep or debug the unit).
The result is that I have identified the line that hangs the
microcontroller.
In the main.c :
//----------------------
/// Configures the RTT to generate a one second tick, which triggers
the RTTINC /// interrupt.
//----------------------
void ConfigureRtt(void)
{
unsigned int previousTime;
printf("Debug point 0.1\n\r");
// Configure RTT for a 1 second tick interrupt
RTT_SetPrescaler(AT91C_BASE_RTTC, 32768);
previousTime = RTT_GetTime(AT91C_BASE_RTTC);
printf("Debug point 0.2\n\r");
while (previousTime == RTT_GetTime(AT91C_BASE_RTTC));
printf("Debug point 0.3\n\r");
// Enable RTT interrupt
AIC_ConfigureIT(AT91C_ID_SYS, 0, ISR_Rtt);
printf("Debug point 0.4\n\r");
AIC_EnableIT(AT91C_ID_SYS);
printf("Debug point 0.5\n\r");
// The line below hangs the system
RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
// This printf never gets outputted to the serialport (actually DBGU)
printf("Debug point 0.6\n\r");
}
Now... Any idea's of how to figure out what is going wrong?
Best regards
JesperKP
Reply by ●June 6, 20102010-06-06
Some development systems support an unlimited number of breakpoints when
debugging in RAM, while the ARM7 jtag interface typically supports just two
breakpoints. I'm not sure how that works with OpenOCD, probably what
you're using with GNU.
----- Original Message -----
From: Maziar Tasbihi
To: A...
Sent: Sunday, June 06, 2010 9:18 AM
Subject: Re: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Hi,
I have not used the the arm7s series, but I have another question, why are you using the RAM version of the compile, is there some special reason? Why dot' you just use the FLASH version of the compile and load it into the internal flash and try executing?
Rgds.
--------
From: Jesper K. Pedersen
To: A...
Sent: Sun, June 6, 2010 4:22:44 AM
Subject: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Having received help here on getting my GNU tool chain working it is
now running like a charm.
I have however run into problems getting the "basic-rtt-project" from
Atmel at91sam7s-ek software up and running.
It compiles fine - but when I upload it to my microcontroller (ram
version) and runs it I get the initial response on my serial
connection :
-- Basic RTT Project 1.5 --
-- AT91SAM7S-EK
-- Compiled: Jun 5 2010 22:52:51 --
And then nothing... The microcontroller seems to hang.
I have tried to insert debug printf's (as I dont have a JTAG to
singlestep or debug the unit).
The result is that I have identified the line that hangs the
microcontroller.
In the main.c :
//----------------------
/// Configures the RTT to generate a one second tick, which triggers
the RTTINC /// interrupt.
//----------------------
void ConfigureRtt(void)
{
unsigned int previousTime;
printf("Debug point 0.1\n\r");
// Configure RTT for a 1 second tick interrupt
RTT_SetPrescaler(AT91C_BASE_RTTC, 32768);
previousTime = RTT_GetTime(AT91C_BASE_RTTC);
printf("Debug point 0.2\n\r");
while (previousTime == RTT_GetTime(AT91C_BASE_RTTC));
printf("Debug point 0.3\n\r");
// Enable RTT interrupt
AIC_ConfigureIT(AT91C_ID_SYS, 0, ISR_Rtt);
printf("Debug point 0.4\n\r");
AIC_EnableIT(AT91C_ID_SYS);
printf("Debug point 0.5\n\r");
// The line below hangs the system
RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
// This printf never gets outputted to the serialport (actually DBGU)
printf("Debug point 0.6\n\r");
}
Now... Any idea's of how to figure out what is going wrong?
Best regards
JesperKP
----- Original Message -----
From: Maziar Tasbihi
To: A...
Sent: Sunday, June 06, 2010 9:18 AM
Subject: Re: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Hi,
I have not used the the arm7s series, but I have another question, why are you using the RAM version of the compile, is there some special reason? Why dot' you just use the FLASH version of the compile and load it into the internal flash and try executing?
Rgds.
--------
From: Jesper K. Pedersen
To: A...
Sent: Sun, June 6, 2010 4:22:44 AM
Subject: [AT91SAM] Problems with getting "basic-rtt-project" up and running on my AT91SAM7S256 (Olimex SAM7P256 board)
Having received help here on getting my GNU tool chain working it is
now running like a charm.
I have however run into problems getting the "basic-rtt-project" from
Atmel at91sam7s-ek software up and running.
It compiles fine - but when I upload it to my microcontroller (ram
version) and runs it I get the initial response on my serial
connection :
-- Basic RTT Project 1.5 --
-- AT91SAM7S-EK
-- Compiled: Jun 5 2010 22:52:51 --
And then nothing... The microcontroller seems to hang.
I have tried to insert debug printf's (as I dont have a JTAG to
singlestep or debug the unit).
The result is that I have identified the line that hangs the
microcontroller.
In the main.c :
//----------------------
/// Configures the RTT to generate a one second tick, which triggers
the RTTINC /// interrupt.
//----------------------
void ConfigureRtt(void)
{
unsigned int previousTime;
printf("Debug point 0.1\n\r");
// Configure RTT for a 1 second tick interrupt
RTT_SetPrescaler(AT91C_BASE_RTTC, 32768);
previousTime = RTT_GetTime(AT91C_BASE_RTTC);
printf("Debug point 0.2\n\r");
while (previousTime == RTT_GetTime(AT91C_BASE_RTTC));
printf("Debug point 0.3\n\r");
// Enable RTT interrupt
AIC_ConfigureIT(AT91C_ID_SYS, 0, ISR_Rtt);
printf("Debug point 0.4\n\r");
AIC_EnableIT(AT91C_ID_SYS);
printf("Debug point 0.5\n\r");
// The line below hangs the system
RTT_EnableIT(AT91C_BASE_RTTC, AT91C_RTTC_RTTINCIEN);
// This printf never gets outputted to the serialport (actually DBGU)
printf("Debug point 0.6\n\r");
}
Now... Any idea's of how to figure out what is going wrong?
Best regards
JesperKP
Reply by ●June 6, 20102010-06-06
On Sun, 6 Jun 2010 06:18:57 -0700 (PDT)
Maziar Tasbihi wrote:
> Hi,
> I have not used the the arm7s series, but I have another question,
> why are you using the RAM version of the compile, is there some
> special reason? Why dot' you just use the FLASH version of the
> compile and load it into the internal flash and try executing? Rgds.
>
As I use the Sam-Ba interface (boot management that accept USB-Serial
connection) it is much easier for me to run small things that are
"learning by doing" stuff instead of programming it into the Flash
memory, which mean I have to run the special Sam-Ba re-installation
each time I need to run a new version of the software.
The software I am trying to learn from is :
http://www.atmel.com/dyn/resources/prod_documents/at91sam7s-ek.zip
In my particular example showing the use of hte RTT unit.
basic-rtt-project-at91sam7s-ek-gnu
Best regards
JesperKP
Maziar Tasbihi wrote:
> Hi,
> I have not used the the arm7s series, but I have another question,
> why are you using the RAM version of the compile, is there some
> special reason? Why dot' you just use the FLASH version of the
> compile and load it into the internal flash and try executing? Rgds.
>
As I use the Sam-Ba interface (boot management that accept USB-Serial
connection) it is much easier for me to run small things that are
"learning by doing" stuff instead of programming it into the Flash
memory, which mean I have to run the special Sam-Ba re-installation
each time I need to run a new version of the software.
The software I am trying to learn from is :
http://www.atmel.com/dyn/resources/prod_documents/at91sam7s-ek.zip
In my particular example showing the use of hte RTT unit.
basic-rtt-project-at91sam7s-ek-gnu
Best regards
JesperKP
Reply by ●June 6, 20102010-06-06
On Sun, 6 Jun 2010 09:39:33 -0400
"Chris DeLise" wrote:
> Some development systems support an unlimited number of breakpoints
> when debugging in RAM, while the ARM7 jtag interface typically
> supports just two breakpoints. I'm not sure how that works with
> OpenOCD, probably what you're using with GNU.
>
I am communicating with the microcontroller over a usb serial
connection that the AT91SAM series support under the name of Sam-Ba
which doesnt allow for breakpoint.
Best regards
JesperKP
"Chris DeLise" wrote:
> Some development systems support an unlimited number of breakpoints
> when debugging in RAM, while the ARM7 jtag interface typically
> supports just two breakpoints. I'm not sure how that works with
> OpenOCD, probably what you're using with GNU.
>
I am communicating with the microcontroller over a usb serial
connection that the AT91SAM series support under the name of Sam-Ba
which doesnt allow for breakpoint.
Best regards
JesperKP
