Re: [Openocd-development] support avr32

[Alan Carvalho de Assis]

Hi Duane,

On 5/28/09, Duane Ellis  wrote:

>
> Imagine
> (1) being able to plug OpenOCD/JTAG into the board.
> (2) using some gerber view program - view the PCB
> (3) Double click on a pin, or a trace with a mouse
> (4) The trace starts blinking
> (5) And openocd makes the trace toggle 0/1
>
> That alone would be a powerful debug tool, no debug software to write,
> no flash to program, no nothing.
>

OpenOCD needs this feature!

I think OpenOCD will need a script to convert the BSDL to some XML or
to a simple standard file (even C source code), then openocd can map
it to JTAG chain. Finally libopenocd will let other software to
control each pin individually.

It makes simple to CAD software (i.e. KiCAD) to do what you suggested.
Also it will make easy to someone create a simple graphical python
interface with all pins from a BGA chip, then you just click on a ball
(a pin) to change its status.

Regards,

Alan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Duane Ellis]

Xiaofan Chen wrote:
> Back to the basic, how can OpenOCD to wiggle a pin (forget
> about the PCB Gerber View integration part)? Is this possible?
> I am not so familiar with JTAG. But intuitively I think this is
> already difficult. Without downloading a small program to
> the chips, how do you toggle an I/O pin?
>
>   
Take a look a this introduction:

http://www.corelis.com/products/Boundary-Scan_Tutorial.htm

The idea is this: If you have a BSDL file, which identifies the JTAG 
commands, the DR scan order (bit order) of all I/O pins... you don't 
need much more.
Step 1: Scan in a zero the pin, Step 2: Scan in a one on the pin, Step 
3: Repeat.

There is no target code involved.

Same method is used to read the pin..

But - back to the "gerber view" - or something like it...  Perhaps a 
chip outline.
Maybe like the Xilinix pin allocation graphic view program.
If you can read all the pins. You can draw "logic 1" pins in one color, 
and 0 in another.
If you keep reading, you could draw "changing" in a different color.

Take that to the next level - ie: Gerber view - and you can make board 
traces blink different colors.

-Duane.





___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Fri, May 29, 2009 at 10:08 AM, Duane Ellis  wrote:
> I'm talking about basic continuity and pin drive, and ability to read a
> digital value on a pin.
>
>  If I had a program that could take the Schematic netlist + the BSDL files
> for a couple complex chips - and give me a SVF file or something like that -
> to verify basic connectivity on the board - wow!

I think this is what the expensive testers and some mid-cost JTAG
tools are doing.

> For those pins attached to a memory device - a simple memory test
> would be powerful.
> If I could get OpenOCD to 'wiggle' a pin - that would be great.
>
> Imagine
>   (1) being able to plug OpenOCD/JTAG into the board.
>   (2) using some gerber view program - view the PCB
>   (3) Double click on a pin, or a trace with a mouse
>   (4) The trace starts blinking
>   (5) And openocd makes the trace toggle 0/1
>
> That alone would be a powerful debug tool, no debug software to write, no
> flash to program, no nothing.
>

Thanks. Indeed this sounds like a great tool for hardware
tests. But I am not so sure about how difficult to integrate this
with a Gerber View program (or full-fledged E-CAD programs).

Back to the basic, how can OpenOCD to wiggle a pin (forget
about the PCB Gerber View integration part)? Is this possible?
I am not so familiar with JTAG. But intuitively I think this is
already difficult. Without downloading a small program to
the chips, how do you toggle an I/O pin?

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Duane Ellis]

duane> [I want a board test feature]

 > How does those higher end tester like Agilent 3070 in circuit tester 
work?
 > Do they require extra add-on for JTAG related stuff like Boundary Scan?
 > Do they use BDSL files? I know they can flash some MCUs but not all.
 > Last time we have to use off-line programming for TMS470R1A64/A256
 > since the support was not ready yet.

I think - while those systems *COULD* do flash programing - the truth is 
something else. The *COST* - in machine time, makes it too expensive.

To be clear: I think big systems like the Agilent have their place, they 
do all kinds of other stuff. However, I believe they all require an 
expensive "bed of nails" fixture, lots of time and money for a 10 board 
prototype run, or fixing a few very expensive test boards

I'm talking about basic continuity and pin drive, and ability to read a 
digital value on a pin, this type of problem:

I built 10 prototype boards - and 4 do not work. What's wrong? I 
don't have an XRAY machine.
These are prototypes, I don't have budget to create bed-of-nails 
fixture, What are my options?
   
If I had a program that could take the Schematic netlist + the BSDL 
files for a couple complex chips - and give me a SVF file or something 
like that - to verify basic connectivity on the board - wow!
For those pins attached to a memory device - a simple memory test would 
be powerful.
If I could get OpenOCD to 'wiggle' a pin - that would be great.

Imagine
(1) being able to plug OpenOCD/JTAG into the board.
(2) using some gerber view program - view the PCB
(3) Double click on a pin, or a trace with a mouse
(4) The trace starts blinking
(5) And openocd makes the trace toggle 0/1

That alone would be a powerful debug tool, no debug software to write, 
no flash to program, no nothing.

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Fri, May 29, 2009 at 7:22 AM, Duane Ellis  wrote:

> No - actually it is useful for other purposes... a method to flash something
> - however slow it may be - is better then no method to flash something, or
> the ability to flash a board with a CPU you do not support.
>
> UrJTAG's approach is to read the BSDL file -figure out the bus structure -
> and read and write memory locations. One could - create  some interesting
> things.
>
> And - most importantly - it can be used to create a "debug tool" useful for
> board bring up. For example - you have a new board you are trying to bring
> up - nothing works - you can use BSDL - to wiggle/pulse a pin and probe it
> out.
>
> I'd be *REALLY* happy if I could create a JTAG hardware test - using BSDL
> files...
>
> Granted, for "production purposes" - it would be very slow. But - for
> "simple prototype work" - it would be great. Sure, production hardware jtag
> tests that take 10 minutes are *TOO*LONG* - however - the ability to perform
> a hardware jtag test on a *SIMPLE* 5 piece prototype build - is another
> matter. I'd let it run over lunch - or while I am in a meeting, when I'm
> back  I know know my prototype is "mostly working" :-) YEA!
>
> That does not yet exist.

How does those higher end tester like Agilent 3070 in circuit tester work?
Do they require extra add-on for JTAG related stuff like Boundary Scan?
Do they use BDSL files? I know they can flash some MCUs but not all.
Last time we have to use off-line programming for TMS470R1A64/A256
since the support was not ready yet.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Duane Ellis]

Alan Carvalho de Assis wrote:
> Hi Duane,
>
> On 5/27/09, Duane Ellis  wrote:
>   
>> FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip
>> flash programing via boundary scan
>>
>> 
> Arggg, then it will not help too much!
No - actually it is useful for other purposes... a method to flash 
something - however slow it may be - is better then no method to flash 
something, or the ability to flash a board with a CPU you do not support.

UrJTAG's approach is to read the BSDL file -figure out the bus structure 
- and read and write memory locations. One could - create  some 
interesting things.

And - most importantly - it can be used to create a "debug tool" useful 
for board bring up. For example - you have a new board you are trying to 
bring up - nothing works - you can use BSDL - to wiggle/pulse a pin and 
probe it out.

I'd be *REALLY* happy if I could create a JTAG hardware test - using 
BSDL files...

Granted, for "production purposes" - it would be very slow. But - for 
"simple prototype work" - it would be great. Sure, production hardware 
jtag tests that take 10 minutes are *TOO*LONG* - however - the ability 
to perform a hardware jtag test on a *SIMPLE* 5 piece prototype build - 
is another matter. I'd let it run over lunch - or while I am in a 
meeting, when I'm back  I know know my prototype is "mostly working" :-) 
YEA!

That does not yet exist.

-Duane.




___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Alan Carvalho de Assis]

Hi Duane,

On 5/27/09, Duane Ellis  wrote:
> FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip
> flash programing via boundary scan
>

Arggg, then it will not help too much!

> There is a variant/fork of UrJTAG - (link below) that ADI supports - a
> private fork ADI maintains - for GDB Remote debug.

Thank you for links,

Alan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Duane Ellis]

alan> I think other processors supported by UrJtag can be ported as well:
alan> MPC5200B, Blackfin, BCM6358, etc

FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip 
flash programing via boundary scan

There is a variant/fork of UrJTAG - (link below) that ADI supports - a 
private fork ADI maintains - for GDB Remote debug.

The blackfin "fork" has uses URJTAG sort of like a jtag library.

The GDB proxy


http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fgdbproxy%2F
 


The URJTAG private fork


http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fjtag%2F
 


-Duane.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Alan Carvalho de Assis]

Hi Xiaofan,

On 5/27/09, Xiaofan Chen  wrote:
> On Thu, May 21, 2009 at 10:22 AM, Tiago Maluta 
> wrote:
>> I'd like to know if OpenOCD support AVR32 (AP7000) processors? I was
>> looking
>> a tool [1] to write the flash memory of Atmel reference design ATNGW100.
>
> It seems to me that UrJtag has some kind of AVR32 support.
> Maybe it can be ported to OpenOCD.
> http://sourceforge.net/project/shownotes.php?release_id=676628
>

I think other processors supported by UrJtag can be ported as well:
MPC5200B, Blackfin, BCM6358, etc

Regards,

Alan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Thu, May 21, 2009 at 10:22 AM, Tiago Maluta  wrote:
> I'd like to know if OpenOCD support AVR32 (AP7000) processors? I was looking
> a tool [1] to write the flash memory of Atmel reference design ATNGW100.

It seems to me that UrJtag has some kind of AVR32 support.
Maybe it can be ported to OpenOCD.
http://sourceforge.net/project/shownotes.php?release_id=676628

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Wed, May 27, 2009 at 2:15 PM, Peter Denison  wrote:
>> Does avrdude support AVR32? I do not know that.
> My mistake - I can only confirm (from experience) that it programs AtMega32
> devices.
>
> The man page for avrdude says that it will program AT90,
> ATmega{8,16,32,48,64,128,256} and ATtiny parts.
>
> I still think that USBprog supports the full JTAGICE protocol though.
>

Again, I am only guessing here. Judging from the forum of
USBprog, maybe you are thinking about the
AVRISP mkII Clone firmware.

http://forum.embedded-projects.net/index.php
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Peter Denison]

On Wed, 27 May 2009, Xiaofan Chen wrote:

> On Wed, May 27, 2009 at 2:29 AM, Peter Denison  wrote:
>> On Mon, 25 May 2009, Xiaofan Chen wrote:
>>> I do not think so. From the website, it does not
>>> even program AVR32 properly as of now.
>>
>> It does. The website is woefully out of date. I have used a USBprog to
>> program AVR32s, using avrdude, and it is also fully recognised by
>> AVR32Studio, when programmed correctly.
>>
>
> Does avrdude support AVR32? I do not know that. Thanks for the
> information. I am not familiar with AVR32.

My mistake - I can only confirm (from experience) that it programs 
AtMega32 devices.

The man page for avrdude says that it will program AT90, 
ATmega{8,16,32,48,64,128,256} and ATtiny parts.

I still think that USBprog supports the full JTAGICE protocol though.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Wed, May 27, 2009 at 2:29 AM, Peter Denison  wrote:
> On Mon, 25 May 2009, Xiaofan Chen wrote:
>> I do not think so. From the website, it does not
>> even program AVR32 properly as of now.
>
> It does. The website is woefully out of date. I have used a USBprog to
> program AVR32s, using avrdude, and it is also fully recognised by
> AVR32Studio, when programmed correctly.
>

Does avrdude support AVR32? I do not know that. Thanks for the
information. I am not familiar with AVR32.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Peter Denison]

On Mon, 25 May 2009, Xiaofan Chen wrote:

> 2009/5/25 SimonQian :
>> For supporting AVR32 debugging under IAR EWAVR32 and
>> AVR32Studio, you MUST emulate JTAGICE mkII.
>
> I see. Thanks.

USBprog does do full JTAGICEmkII emulation, I believe - I haven't tested 
it myself doing debugging, but I think it's all there

>> Does USBprog support AVR32 debugging?
>>
> I do not think so. From the website, it does not
> even program AVR32 properly as of now.

It does. The website is woefully out of date. I have used a USBprog to 
program AVR32s, using avrdude, and it is also fully recognised by 
AVR32Studio, when programmed correctly.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

2009/5/26 Michel Catudal :
> Then Fedora 9 should work for you if my Ubuntu script is not complete for
> that. I know it will compile on Fedora 9 but not sure yet on Ubuntu.
> I will have the binary and source by week end.

Thanks a lot. I will take a look. I have a starter kit for XE166 but
I have not used it. Infineon CAN parts (C167 and 8051) used to
be popular here but not any more since ARM takes over.

>>> I do have GCC for Renesas as well. If someone needs it I would need to
>>> recompile it under the new systems.
>>> Last I worked with it was with Fedora 8. I do have the latest source for
>>> Renesas.
>
> I may have this one done by next week but not certain. Before I put it up I
> have to make sure the package compiles good. I don't have a script made
> for Ubuntu but I should be able to adapt my arm script for it. The
> difference for compilation are minor. Do you need C++ or not?
>

No I do not need C++. What I am more interested is the one
for R8C/M16C/M32C.

> If some preference is made on one over the other I would suggest to put
> more importance on the AVR32 devices not targeted for Linux as they are
> the likely devices to be use for most small embedded designs. Unlike the
> bigger AVR32 devices they do not require uboot but require some form of
> JTAG debugging much like ARM7 or cortex devices.

Agreed.

> Parallel designs should be in place. I am very interested in having a
> PIC32 debug working and am spending time on this effort. I will not
> present any patches until I get something
> working to my satisfaction. I would like to be informed though if anyone
> else is working on it so we can exchange ideas.

Thanks for the information.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Michel Catudal]

Xiaofan Chen a écrit :
> 2009/5/25 Michel Catudal :
>
>   
>>> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
>>> support.
>>>   
>> Incorrect, I have one, do you need it? I could provide some binaries on
>> my web site if I have space left.
>> It is about two years old, I am trying to get the lastest source but am
>> having some problem with the company who so far
>> has refused to abide by the GPL. They did provide me with the source a
>> couple of years ago.
>> I may look into updating the new sources myself but this is not my top
>> priority at the moment.
>> Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE
>> 11.1 and Ubuntu 8.10 systems.
>> 
>
> Source codes and build instructions are the best. If not, Ubuntu will be
> good since that is my main distro (now 9.04/8.10). I also use Fedora 10.
>
>   
Then Fedora 9 should work for you if my Ubuntu script is not complete 
for that. I know it will compile on Fedora 9 but not sure yet on Ubuntu.
I will have the binary and source by week end.
This would be the two year old version as I haven't been successfull 
into getting the latest source yet.
The funny part about the company in question, they have recently bought 
part of a company that my employer had outsourced to a few years ago.
The beauty of outsourcing ... I spent over a month fixing the mess as we 
were about to lose a multi million dollars contract. When the customer
found out that I was again in charge they calmed down.
Last week when we discussed the different compilers for infineon we had 
a good laugh when I noticed that.

>> I do have GCC for Renesas as well. If someone needs it I would need to
>> recompile it under the new systems.
>> Last I worked with it was with Fedora 8. I do have the latest source for
>> Renesas.
>>
>> 
>
> Again, Source codes and build instructions are the best. If not, Ubuntu will 
> be
> good since that is my main distro (now 9.04/8.10). I also use Fedora 10
> and Arch Linux (testing purpose only).
>   
I may have this one done by next week but not certain. Before I put it 
up I have to make sure the package compiles good. I don't have a script made
for Ubuntu but I should be able to adapt my arm script for it. The 
difference for compilation are minor. Do you need C++ or not?

I have been using SuSE 11.1 for a while but all of a sudden my mouse 
double click no longer work after an update so for now most of
my work is on Fedora 9. I will install Fedora 11 shortly. I have 
installed Ubuntu out of curiosity and so I can support systems where I 
install Ubuntu,
but I am not impressed, Redhat is superior and packaging creation is not 
as much a pain as it with Ubuntu. I usually prefer to install Ubuntu for 
people
in the family who don't know anything about Linux as it presents me less 
work but for my own use, no way.




-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

2009/5/25 Michel Catudal :

>> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
>> support.
>
> Incorrect, I have one, do you need it? I could provide some binaries on
> my web site if I have space left.
> It is about two years old, I am trying to get the lastest source but am
> having some problem with the company who so far
> has refused to abide by the GPL. They did provide me with the source a
> couple of years ago.
> I may look into updating the new sources myself but this is not my top
> priority at the moment.
> Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE
> 11.1 and Ubuntu 8.10 systems.

Source codes and build instructions are the best. If not, Ubuntu will be
good since that is my main distro (now 9.04/8.10). I also use Fedora 10.

> I do have GCC for Renesas as well. If someone needs it I would need to
> recompile it under the new systems.
> Last I worked with it was with Fedora 8. I do have the latest source for
> Renesas.
>

Again, Source codes and build instructions are the best. If not, Ubuntu will be
good since that is my main distro (now 9.04/8.10). I also use Fedora 10
and Arch Linux (testing purpose only).


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Michel Catudal]

Nico Coesel a écrit :
> FYI: 
> Coldfire = 68000
> Codesourcery offers precompiled GCC with Coldfire support. Maybe
> Freescale can be persuaded to donate some hardware. They are losing
> designs because they are currently forcing their customers to use
> Codewarrior.
>   
The Codewarrior crap is just part of the problems with Freescale.

Some people have some other reason to ignore them
http://www.reuters.com/article/innovationNewsTechMediaTelco/idUSTRE52U58720090331

There is also the huge debt which make people believe that the company
may be near collapse.
They were bought by the Carlyle Group at 4 times its value.

Michel

-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Michel Catudal]

Xiaofan Chen a écrit :
> On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen  wrote:
>   
>> There are many 16/32bit MCUs which will benefit from OpenOCD if
>> they are supported. Most popular non-ARM ones I can think of are Renesas
>> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
>>
>> Just look at this chart for top 10 MCU vendors.
>> http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif
>> 
>
> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
> support. 

Incorrect, I have one, do you need it? I could provide some binaries on
my web site if I have space left.
It is about two years old, I am trying to get the lastest source but am
having some problem with the company who so far
has refused to abide by the GPL. They did provide me with the source a
couple of years ago.
I may look into updating the new sources myself but this is not my top
priority at the moment.
Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE
11.1 and Ubuntu 8.10 systems.
I do have GCC for Renesas as well. If someone needs it I would need to
recompile it under the new systems.
Last I worked with it was with Fedora 8. I do have the latest source for
Renesas.

> So even though they have free DAS JTAG server which supports
> cheap USB Jtag tools, it may not be that effective to offer OpenOCD support.
> ftp://ftp.extra.infineon.com/MC_Skits_SW/UC-UConnect_XE164/Tools/DAS/DAS_Product_Brief_v1_0.pdf
>
> M16C and H8/H8S do have gcc support. But I do not know if there are any
> cheap non-Renesas debugging tools for them. Renesas tools are getting
> cheaper though. I even got a free M16C Tiny kit (a USB debugger and
> a startkit board) from them just by visiting their website and put in some
> contact information.
>
> I am not familiar with Fujitsu and NEC MCUs.
>
>   
Fujitsu micros require an emulator. I work with them on gauges and
clusters. The emulator cost us about $12000

NEC has some real low cost 8 bits micros, some 16 bits and 32 bits
micros also relatively low cost.
Future is the distributor.

You can get a debugger for the 8 bits devices for about $150 for the 8K
devices.

> So I will vote for PIC32 support first (being a Microchip fan and since the
> support is more or less in place), then MSP430/AVR32/AVR support, then
> ColdFire support. But of course the priority should be to get ARM
> stable with different cores. ST, TI/Luminary, Atmel, NXP (No 6 to 10)
> are all ARM MCU Vendors.
>
>   
My impression so far is that Atmel is probably farther ahead than
Microchip on the 32 bits devices. Microchip seems very far behind in the
automotive industry.
I should find out more this week. I won't be able to give any specific
details on their plan but I can say that they are not ready for me to
take them seriously for new designs.
Atmel doesn't have full documentation on the CAN AVR32 devices because
they are waiting for the demo boards to be out. Parts were available for
sampling last year.

Because Atmel is much friendlier to the opensource I would vote for them
if there was to be one over the other. I still think that both types of
devices need serious
consideration. Microchip is not very friendly to the opensource world
but their stuff works. I am always fascinated with their devices when we
do the harsh environment tests.
I hate the Microchip banking shit on the 8 bits devices but hardware
wise they are hard to beat. One could assume that their 32 bits devices
will be just as good.

If some preference is made on one over the other I would suggest to put
more importance on the AVR32 devices not targeted for Linux as they are
the likely devices to be use for most small embedded designs. Unlike the
bigger AVR32 devices they do not require uboot but require some form of
JTAG debugging much like ARM7 or cortex devices.

Parallel designs should be in place. I am very interested in having a
PIC32 debug working and am spending time on this effort. I will not
present any patches until I get something
working to my satisfaction. I would like to be informed though if anyone
else is working on it so we can exchange ideas.

Michel


-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Nico Coesel]

> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de 
> [mailto:openocd-development-boun...@lists.berlios.de] Namens 
> Xiaofan Chen
> Verzonden: maandag 25 mei 2009 10:54
> Aan: openocd-development@lists.berlios.de
> Onderwerp: Re: [Openocd-development] support avr32
> 
> On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen 
>  wrote:
> >
> > There are many 16/32bit MCUs which will benefit from 
> OpenOCD if they 
> > are supported. Most popular non-ARM ones I can think of are Renesas 
> > M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
> >
> > Just look at this chart for top 10 MCU vendors.
> > 
> http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTR
> > LD_NT_01.gif
> 
> Within theses chips and ColdFire, Infineon XE166 does not 
> seem to have gcc support. So even though they have free DAS 

FYI: 
Coldfire = 68000
Codesourcery offers precompiled GCC with Coldfire support. Maybe
Freescale can be persuaded to donate some hardware. They are losing
designs because they are currently forcing their customers to use
Codewarrior.

The Renesas controllers are another story. Turning the code read
protection on requires an NDA so OpenOCD is not likely to be able to
support code read protection on Renesas chips.

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen  wrote:
>
> There are many 16/32bit MCUs which will benefit from OpenOCD if
> they are supported. Most popular non-ARM ones I can think of are Renesas
> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
>
> Just look at this chart for top 10 MCU vendors.
> http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif

Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
support. So even though they have free DAS JTAG server which supports
cheap USB Jtag tools, it may not be that effective to offer OpenOCD support.
ftp://ftp.extra.infineon.com/MC_Skits_SW/UC-UConnect_XE164/Tools/DAS/DAS_Product_Brief_v1_0.pdf

M16C and H8/H8S do have gcc support. But I do not know if there are any
cheap non-Renesas debugging tools for them. Renesas tools are getting
cheaper though. I even got a free M16C Tiny kit (a USB debugger and
a startkit board) from them just by visiting their website and put in some
contact information.

I am not familiar with Fujitsu and NEC MCUs.

So I will vote for PIC32 support first (being a Microchip fan and since the
support is more or less in place), then MSP430/AVR32/AVR support, then
ColdFire support. But of course the priority should be to get ARM
stable with different cores. ST, TI/Luminary, Atmel, NXP (No 6 to 10)
are all ARM MCU Vendors.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Mon, May 25, 2009 at 12:46 PM, David Brownell  wrote:
> On Sunday 24 May 2009, SimonQian wrote:
>> I have developped JTAG support for MSP430 in versaloon, as I know, JTAG
>> chain of MSP430 isn't standard JTAG. So I don't think it possible to support
>> MSP430 in OpenOCD.
>
> Could you summarize how msp430 is non-standard?
>
> I know that msp430 -- as well as the C200 microcontrollers -- can
> be programmed using an ft2232c based "XDS100" [1] adapter.  Which is
> certainly self-described as a JTAG adapter ... albeit one that
> also controls the EMU0 and EMU1 outputs that TI likes.
>
> So I'd kind of thought that any differences between MSP430 and
> other JTAGs are more at the level of minor goofage than anything
> very significant.  Like maybe problems co-existing on standard
> JTAG scan chains.
>

I do not know about this myself. Maybe this will help.
http://xgoat.com/wp/2009/03/25/fetproxy-an-open-source-replacement-for-msp430-gdbproxy/

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[David Brownell]

On Sunday 24 May 2009, SimonQian wrote:
> I have developped JTAG support for MSP430 in versaloon, as I know, JTAG 
> chain of MSP430 isn't standard JTAG. So I don't think it possible to support 
> MSP430 in OpenOCD.

Could you summarize how msp430 is non-standard?

I know that msp430 -- as well as the C200 microcontrollers -- can
be programmed using an ft2232c based "XDS100" [1] adapter.  Which is
certainly self-described as a JTAG adapter ... albeit one that
also controls the EMU0 and EMU1 outputs that TI likes.

So I'd kind of thought that any differences between MSP430 and
other JTAGs are more at the level of minor goofage than anything
very significant.  Like maybe problems co-existing on standard
JTAG scan chains.

- Dave

[1] http://tiexpressdsp.com/wiki/index.php?title=XDS100
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

2009/5/25 SimonQian :
> For supporting AVR32 debugging under IAR EWAVR32 and
> AVR32Studio, you MUST emulate JTAGICE mkII.

I see. Thanks.

> Does USBprog support AVR32 debugging?
>

I do not think so. From the website, it does not
even program AVR32 properly as of now.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[SimonQian]

For supporting AVR32 debugging under IAR EWAVR32 and 
AVR32Studio, you MUST emulate JTAGICE mkII.
Does USBprog support AVR32 debugging?


2009-05-25 



Best Regards, Simon Qian

SimonQian(simonq...@simonqian.com)  www.SimonQian.com



发件人： Xiaofan Chen 
发送时间： 2009-05-25  11:36:35 
收件人： SimonQian 
抄送： David Brownell; openocd-development 
主题： Re: Re: [Openocd-development] support avr32 
 
2009/5/25 SimonQian :
> I can test for AVR32 support.
> My company is handling with some projects on AVR32.
>
> My versaloon can also support AVR32 debug and program
> under IAR EWAVR32 or AVR32Studio according to the open
> protocol from atmel.
By emulating JTAGICE mkII ?
> The open source version and product�version�of versaloon
> doesn't support AVR32, because it will use JTAGICE mkII's
> VID/PID of Atmel.
I do not quite understand what you mean. Why do you
need to use the VID/PID of Atmel? Is it because your
firmware is simulating a JTAGICE mkII and the IAR/Atmel
tool check for the VID/PID?
-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[SimonQian]

> There are many 16/32bit MCUs which will benefit from OpenOCD if
> they are supported. Most popular non-ARM ones I can think of are Renesas
> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
I have developped JTAG support for MSP430 in versaloon, as I know, JTAG 
chain of MSP430 isn't standard JTAG. So I don't think it possible to support 
MSP430 in OpenOCD.

2009-05-25 



Best Regards, Simon Qian

SimonQian(simonq...@simonqian.com)  www.SimonQian.com



发件人： Xiaofan Chen 
发送时间： 2009-05-25  11:28:33 
收件人： michelcatudal 
抄送： openocd-development 
主题： Re: [Openocd-development] support avr32 
 
2009/5/25 Michel Catudal :
> David Brownell a �crit :
>> ? AVR32-specific support. �Probably not just the AP7 devices,
>> ?�but also the UC3 flavors (since those seem to be getting
>> ?�the engineering work nowadays).
>>
> I would agree with that. From what I have read the AVR32 is likely to
> compete with NEC's V850 and Cortex devices in the next few years.
ColdFire V1 and V2/V3/V4 support will be nice as well.
> The devices with CAN are supposed to come out shortly. This will make
> this device very important for us Engineers.
> Support for OpenOCD will be very usefull.
>
There are many 16/32bit MCUs which will benefit from OpenOCD if
they are supported. Most popular non-ARM ones I can think of are Renesas
M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
Just look at this chart for top 10 MCU vendors.
http://www.eetasia.com/ART_8800570077_1034362_NT_9b19f76b.HTM
http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif
I guess that this will take a long time.
-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

2009/5/25 SimonQian :
> I can test for AVR32 support.
> My company is handling with some projects on AVR32.
>
> My versaloon can also support AVR32 debug and program
> under IAR EWAVR32 or AVR32Studio according to the open
> protocol from atmel.

By emulating JTAGICE mkII ?

> The open source version and product version of versaloon
> doesn't support AVR32, because it will use JTAGICE mkII's
> VID/PID of Atmel.

I do not quite understand what you mean. Why do you
need to use the VID/PID of Atmel? Is it because your
firmware is simulating a JTAGICE mkII and the IAR/Atmel
tool check for the VID/PID?

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[SimonQian]

I can test for AVR32 support.
My company is handling with some projects on AVR32.

My versaloon can also support AVR32 debug and program 
under IAR EWAVR32 or AVR32Studio according to the open 
protocol from atmel.
The open source version and product version of versaloon 
doesn't support AVR32, because it will use JTAGICE mkII's 
VID/PID of Atmel.


2009-05-25 



Best Regards, Simon Qian

SimonQian(simonq...@simonqian.com)  www.SimonQian.com



发件人： Xiaofan Chen 
发送时间： 2009-05-25  11:18:37 
收件人： David Brownell 
抄送： openocd-development 
主题： Re: [Openocd-development] support avr32 
 
On Mon, May 25, 2009 at 9:06 AM, David Brownell  wrote:
> The simplest way to update the flash on that board would
> be to use the U-Boot that's already installed there. �If
> you brick the board, the next simplest solution is to use
> one of Atmel's JTAG adapters with their tools. �I don't
> know if their tools will let you re-flash with anything
> short of their $300 JTAGICE mkII product; the $50 Dragon
> seems like it ought to suffice.
>
You can use cheaper alternatives like usbprog for Avr32 in the
future. It only costs Euro 35. But it is not stable yet.
http://www.embedded-projects.net/index.php?page_id=236
http://forum.embedded-projects.net/viewtopic.php?id=175
There are also many clones for JTAGICE mkII which
costs less than half of the original...
-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

2009/5/25 Michel Catudal :
> David Brownell a écrit :
>>  - AVR32-specific support.  Probably not just the AP7 devices,
>>    but also the UC3 flavors (since those seem to be getting
>>    the engineering work nowadays).
>>
> I would agree with that. From what I have read the AVR32 is likely to
> compete with NEC's V850 and Cortex devices in the next few years.

ColdFire V1 and V2/V3/V4 support will be nice as well.

> The devices with CAN are supposed to come out shortly. This will make
> this device very important for us Engineers.
> Support for OpenOCD will be very usefull.
>

There are many 16/32bit MCUs which will benefit from OpenOCD if
they are supported. Most popular non-ARM ones I can think of are Renesas
M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.

Just look at this chart for top 10 MCU vendors.
http://www.eetasia.com/ART_8800570077_1034362_NT_9b19f76b.HTM
http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif

I guess that this will take a long time.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Xiaofan Chen]

On Mon, May 25, 2009 at 9:06 AM, David Brownell  wrote:
> The simplest way to update the flash on that board would
> be to use the U-Boot that's already installed there.  If
> you brick the board, the next simplest solution is to use
> one of Atmel's JTAG adapters with their tools.  I don't
> know if their tools will let you re-flash with anything
> short of their $300 JTAGICE mkII product; the $50 Dragon
> seems like it ought to suffice.
>

You can use cheaper alternatives like usbprog for Avr32 in the
future. It only costs Euro 35. But it is not stable yet.
http://www.embedded-projects.net/index.php?page_id=236
http://forum.embedded-projects.net/viewtopic.php?id=175

There are also many clones for JTAGICE mkII which
costs less than half of the original...

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[Michel Catudal]

David Brownell a écrit :
> On Wednesday 20 May 2009, Tiago Maluta wrote:
>   
>> I'd like to know if OpenOCD support AVR32 (AP7000) processors?
>> 
>
> Not yet.  I'd partition that work in two parts:
>
>  - "Nexus" [3] framework, which could support more than
>just the AVR32 chips.
>
>  - AVR32-specific support.  Probably not just the AP7 devices,
>but also the UC3 flavors (since those seem to be getting
>the engineering work nowadays).
>   
I would agree with that. From what I have read the AVR32 is likely to
compete with NEC's V850 and Cortex devices in the next few years.

The devices with CAN are supposed to come out shortly. This will make
this device very important for us Engineers.
Support for OpenOCD will be very usefull.


-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] support avr32

[David Brownell]

On Wednesday 20 May 2009, Tiago Maluta wrote:
> I'd like to know if OpenOCD support AVR32 (AP7000) processors?

Not yet.  I'd partition that work in two parts:

 - "Nexus" [3] framework, which could support more than
   just the AVR32 chips.

 - AVR32-specific support.  Probably not just the AP7 devices,
   but also the UC3 flavors (since those seem to be getting
   the engineering work nowadays).

If I understand correctly, the Nexus bits should suffice to
let you update the NOR flash on that board, and you wouldn't
actually need to interact with the CPU.

The simplest way to update the flash on that board would
be to use the U-Boot that's already installed there.  If
you brick the board, the next simplest solution is to use
one of Atmel's JTAG adapters with their tools.  I don't
know if their tools will let you re-flash with anything
short of their $300 JTAGICE mkII product; the $50 Dragon
seems like it ought to suffice.

- Dave

[3] http://www.nexus5001.org/standard.html


> I was looking 
> a tool [1] to write the flash memory of Atmel reference design ATNGW100.
> From this maillist history I saw a thread [2] discussing how to add a new
> target but no further discussion.
> 
> [1] http://www.sparkfun.com/commerce/product_info.php?products_id=13
> [2] 
> https://lists.berlios.de/pipermail/openocd-development/2009-February/004707.html
> 
> Is it possible using that to rewrite, for example, u-boot in my board?
> 
> Best regards,
> 
> 
> --tm
> 


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] support avr32

[Tiago Maluta]

I'd like to know if OpenOCD support AVR32 (AP7000) processors? I was looking
a tool [1] to write the flash memory of Atmel reference design ATNGW100.
>From this maillist history I saw a thread [2] discussing how to add a new
target but no further discussion.

[1] http://www.sparkfun.com/commerce/product_info.php?products_id=13
[2]
https://lists.berlios.de/pipermail/openocd-development/2009-February/004707.html

Is it possible using that to rewrite, for example, u-boot in my board?

Best regards,


--tm
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development