Hi,

I'm just starting with the IAR starter kit for AT91SAM7X256 processor
and J-Link debugging equipment.
I created a new project with the standard option and set the project
options in the IAR software for debugging with J-Link.
When I start the debugger, IAR seems to download the code to the
board, but when the code runs it doesn't light the LEDS as I expected
and when I pause the code I don't see the stop point in the C-code.
But the dissasembly window opens and I can't step through the code.
I have the impression that the code isn't being downloaded to the
board at all.
I previously compiled and downloaded the RTOS demo for the board and
that works.

Has anybody else had a similar experience?

Thanks,
Martin.



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- francach wrote:

> Hi,
>
> I'm just starting with the IAR starter kit for
> AT91SAM7X256 processor
> and J-Link debugging equipment.
> I created a new project with the standard option and
> set the project
> options in the IAR software for debugging with
> J-Link.

In the project options you can check a box to verify
download. With that you can be certain that the code
is downloaded properly. You can also uncheck the
option to "Run to Main" so the debugger will point to
the first instruction in the program. Right after that
are some exception vectors that usually point to
themselves (in default code examples). If you take an
exception and one of these exceptions is triggered
then it will appear to not be executing since the PC
never changes. The address (as seen in the
dissassembly window) is usually very low, 0008 or
0010. You can also begin execution by stepping at
assembly level to see that there is code and it is
being executed sequentially. You can try jumping ahead
a little to see if you can find the instruction where
it bombs.

You almost certainly want to have RAM mapped to
location 0 if your code will take any interrupts at
all. This remapping is often done in the debugger
startup macros and is a common source of problem. It
is not hard to write some assembler code that you
include in the startup section. It would test to see
if remapping is needed, and do it when necessary.

AW

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- In A...@yahoogroups.com, Alexander Whiplash
wrote:
> --- francach wrote:
>
> > Hi,
> >
> > I'm just starting with the IAR starter kit for
> > AT91SAM7X256 processor
> > and J-Link debugging equipment.
> > I created a new project with the standard option and
> > set the project
> > options in the IAR software for debugging with
> > J-Link.
>
> In the project options you can check a box to verify
> download. With that you can be certain that the code
> is downloaded properly. You can also uncheck the
> option to "Run to Main" so the debugger will point to
> the first instruction in the program. Right after that
> are some exception vectors that usually point to
> themselves (in default code examples). If you take an
> exception and one of these exceptions is triggered
> then it will appear to not be executing since the PC
> never changes. The address (as seen in the
> dissassembly window) is usually very low, 0008 or
> 0010. You can also begin execution by stepping at
> assembly level to see that there is code and it is
> being executed sequentially. You can try jumping ahead
> a little to see if you can find the instruction where
> it bombs.
>
> You almost certainly want to have RAM mapped to
> location 0 if your code will take any interrupts at
> all. This remapping is often done in the debugger
> startup macros and is a common source of problem. It
> is not hard to write some assembler code that you
> include in the startup section. It would test to see
> if remapping is needed, and do it when necessary.
>
> AW
> _

Hi Alexander,

thanks for your hints.
I set the check download option and unchecked the run to main option.
I get some interesting warnings:
"Target inconsistency detected at Memory Address 0x00008258
(and the same message for the addresses 0x00000000, 0x00008338,
0x00000020)
"Failed to set breakpoint at 0x00008320(out of hardware breakpoints)"

The program is stopped at address 0x00000000 and when I do single step
the warnings
"The stack 'CSTACK' is filled to 100%(8192 bytes used out of 8192) The
warning threshold is set to 90%."
"The stack 'IRQ_STACK' is filled to 100%(256 bytes used out of 256)
The warning threshold is set to 90%."
__________

I don't understand how the stack can be completely full after single
stepping a single instruction. This what my program looks like:
int
main( void ){

// Enable IOB clock
AT91F_PIOB_CfgPMC();
AT91F_PIO_CfgOutput(AT91C_BASE_PIOB,AT91B_LED1 );
AT91F_PIO_ClearOutput(AT91C_BASE_PIOB,AT91B_LED1 );
while(1){ ;}
}

The idea is just to light one of the leds.

Thanks for any tips,

Martin.

______________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- francach wrote:

> I set the check download option and unchecked the
> run to main option.
> I get some interesting warnings:
> "Target inconsistency detected at Memory Address
> 0x00008258
> (and the same message for the addresses 0x00000000,
> 0x00008338,
> 0x00000020)
> "Failed to set breakpoint at 0x00008320(out of
> hardware breakpoints)"
>
> The program is stopped at address 0x00000000 and
> when I do single step
> the warnings
> "The stack 'CSTACK' is filled to 100%(8192 bytes
> used out of 8192) ...

Target inconsistency could be due to having flash ROM
at that address instead of RAM. You can open a memory
window (under View) to test for that. Go to address 0,
or 0x8320 if you prefer. Overwrite a byte or two by
placing the cursor over some data and typing. If it
can be changed then you are in RAM as expected. If it
reverts back then it was not able to change that data,
which means that you are looking at ROM now, and the
remap was not done.

The first instruction of your program needs to be C
startup code. That is code is that usually
automatically kinked in with your source. One of the
things that it does is to setup the C stack. Sounds
like this code was not present or was not executed.

As far as not having enough breakpoints, you only get
two if you are using hardware breakpoints. That is a
hardware limitation. When running code in RAM
(recommended) you can have an unlimited number of
breakpoints. There is a switch somewhere under the
debugger configuration window that you should set to
"Auto" for type of breakpoints.

AW
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

--- In A...@yahoogroups.com, Alexander Whiplash
wrote:
> --- francach wrote:
>
> > I set the check download option and unchecked the
> > run to main option.
> > I get some interesting warnings:
> > "Target inconsistency detected at Memory Address
> > 0x00008258
> > (and the same message for the addresses 0x00000000,
> > 0x00008338,
> > 0x00000020)
> > "Failed to set breakpoint at 0x00008320(out of
> > hardware breakpoints)"
> >
> > The program is stopped at address 0x00000000 and
> > when I do single step
> > the warnings
> > "The stack 'CSTACK' is filled to 100%(8192 bytes
> > used out of 8192) ...
>
> Target inconsistency could be due to having flash ROM
> at that address instead of RAM. You can open a memory
> window (under View) to test for that. Go to address 0,
> or 0x8320 if you prefer. Overwrite a byte or two by
> placing the cursor over some data and typing. If it
> can be changed then you are in RAM as expected. If it
> reverts back then it was not able to change that data,
> which means that you are looking at ROM now, and the
> remap was not done.
>
> The first instruction of your program needs to be C
> startup code. That is code is that usually
> automatically kinked in with your source. One of the
> things that it does is to setup the C stack. Sounds
> like this code was not present or was not executed.
>
> As far as not having enough breakpoints, you only get
> two if you are using hardware breakpoints. That is a
> hardware limitation. When running code in RAM
> (recommended) you can have an unlimited number of
> breakpoints. There is a switch somewhere under the
> debugger configuration window that you should set to
> "Auto" for type of breakpoints.
>
> AW
>
____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>

Hi Alexander,

thanks for the tip. Yes you were obviously right about the remap. I
tried altering the values in the memory window, which didn't work. So
I've taken the mac file in the examples directory. However I've still
got the messages:

"The stack 'CSTACK' is filled to 100%(8192 bytes used out of 8192) The
warning threshold is set to 90%."
"The stack 'IRQ_STACK' is filled to 100%(256 bytes used out of 256)
The warning threshold is set to 90%."

And the LED still doesn't seitch on!
So I obviously need to configure something else for the debugger.
Thanks,

Martin.
__________



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )