EmbDev.net

Forum: ARM programming with GCC/GNU tools AT91SAM7S256 ID CODE


Author: Dominique Micollet (Company: Burgundy University) (miko_the_french)
Posted on:

Rate this post
0 useful
not useful
Hello,

First post to this forum.

I am a newbie with ARM processors and have a lot of questions... :-)

For some days I am playing with an Olimex SAM7-MT-256 board, on a linux 
development platform.

I have a "problem" with the identification of the processor, which is an 
AT91SAM7S256.

Whatever was the jtag software I used (openocd or urjtag), I got 
0X3F0F0F0 as ID CODE where I am expecting 0x05B0903F, if I well 
understand the page 56 of the AT91SAM7 Preliminary document
(http://www.atmel.com/dyn/resources/prod_documents/6175s.pdf).

I asked Olimex who answered that this is normal as I got the ARM ID CODE 
and not the ATMEL ID CODE.

This susprises me. For example, I guess that urjtag relies on the 
part/manufacturer code to autoconfigure.

Please, could somebody owning the same board or an other one confirm the 
ID code he gets, or explains me where I am wrong ?

The jtag cable is an olimex ARM-USB-TINY-H.

Sincerely yours

Dominique

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Try to follow the code in the function at91sam7_read_part_info of 
OpenOCD which shows how the model can be identified: 
http://openocd.git.sourceforge.net/git/gitweb.cgi?...

Author: Dominique Micollet (Company: Burgundy University) (miko_the_french)
Posted on:

Rate this post
0 useful
not useful
Hello,

Martin Thomas wrote:
> Try to follow the code in the function at91sam7_read_part_info of
> OpenOCD which shows how the model can be identified:

Thanks for this suggestion.

But if I correctly understand this code, it refers to the CIDR register 
(as described on §9.5 on page 32 of the AT91SAM7 Preliminary (1)) and 
not the JTAG ID Code Register (as described on §12.5.5 on page 56 of the 
same document). The CIDR is Atmel specific (value 0x270B0942) when the 
JTAG ID Code Register is JTAG standardized (0x05B0903F).

From what I understand from the data provided with the urjtag software, 
this JTAG ID Code may help to auto-configure the software : the 
0x05B0903F value is correctly referenced in this data (2).
The problem is that the AT91SAM7S256 on the Olimex board seems to 
provide the 0x30F0F0F JTAG ID Code, which is a generic ARM code (always 
guessed from the urjtag MANUFACTURERS data).

Clearly I am confused, but I do not know why :
- do I misunderstand the use of the JTAG ID Code ?
- do I misuse the jtag software (both openocd and urjtag provide the 
same JTAG ID Code) or the jtag cable ?
- is there a bug somewhere (software of hardware) ?

I would greatly appreciate any advice or suggestion. Especially, could 
somebody recommend a good primer to JTAG, field in which I am completely 
novice ?

Sincerely yours.

(1) By the way, is there an acronym to refer to this document ?
(2) I am unable to find the same kind of data in the openocd software

Author: Ibiza (Guest)
Posted on:

Rate this post
0 useful
not useful
In order to enable IEEE 1149.1 boundary-scan test controller inside 
AT91SAM7S devices, JTAGSEL pin should be tied high. JTAGSEL pin selects 
whether ARM JTAG ICE debug controller (JTEGSEL = 0) or IEEE 1149.1 
boundary-scan test controller (JTAGSEL=1) is enabled and connected to 
JTAG TAP (test access port) pins (TDI, TCK, TMS, TDO).

By default JTAGSEL is internally pulled low, so ARM JTAG ICE debug logic 
is selected and that is why your chip is detected with ARM JTAG ICE 
IDCODE.

I successfully did boundary-scan testing on similar chip (AT91SAM7S64) 
with JTAGSEL=1 using TopJTAG Probe http://www.topjtag.com software. When 
JTAGSEL=1, this software detected this chip's manufacturer as ATMEL and 
IDCODE was the same as in datasheet and BSDL file.

Author: Dominique Micollet (Company: Burgundy University) (miko_the_french)
Posted on:

Rate this post
0 useful
not useful
Ibiza wrote:
> In order to enable IEEE 1149.1 boundary-scan test controller inside
> AT91SAM7S devices, JTAGSEL pin should be tied high.

Thanks for this clue. Knowing what to look for I finally found some 
information in the Atmel documentation.

>
> I successfully did boundary-scan testing on similar chip (AT91SAM7S64)
> with JTAGSEL=1 using TopJTAG Probe http://www.topjtag.com software.

On the SAM7-MT-256 board, the JTAGSEL pin could be set high with a 
jumper. I tried and succesfully got the Atmel identification of the 
AT91SAM7S256, with urjtag software and ARM-USB-TINY-H jtag cable.

I have not yet tried openocd.

Great thanks for your help.

Dominique.

Author: Dereck Wonnacott (Guest)
Posted on:

Rate this post
0 useful
not useful
I am also new to Arm programming, I was having the same issue and you 
helped me fix my issue.

I was getting ID 0x05b0903f with openOCD on my Olimex sam7-P256 dev 
board. I removed the BDS Jumper and OpenOCD connected without errors.

Also, I have the Tiny-H jtag as well and had to add 'jtag_khz 15000' to 
my openocd cfg file above the 'jtag newtap ...'

Hope this might help others in the future :)

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.