On Sun, 10 Oct 2004 08:56:21 -0500, DirtyOldMan
<DirtyOldMan188@yahoo.com> wrote:

>erol.benoz@tnn.net (Erol) wrote in news:5e4da3b5.0409071025.5b3770c0
>@posting.google.com:
>
>> I bought a wiggler probe for ARM7 and was very disappointed when I
>> didn't receive a Flash Programmer Utility with it! Apparently they
>> sell the Flash Programmer SW for 500 extra bucks!
>> 
>> I am not eager to pay any additional dollars to this company,
>> so I would like to know if the wiggler can be used with any other
>> Flash Programmer software.
>> 
>> Thanks,
>> 
>> Erol
>> 
>> P.S. I heard that the OCD Commander SW can be used to download
>> Flash programming SW into target RAM, but I prefer an easier solution
>> if possible.
>
>I realise this is an old post but I am about to develop a flash loader
>for the STR710 through the Wiggler.
>
>My approach is going to be use OCDLibRemote to set up the TCP server on 
>localhost port 8888 and connect to it using a C++ builder application.
>
>I have not developed the download code yet but it only took a few minutes 
>to set up a simple test program and connect to the wiggler in this 
>manner.
>
>The GDB commands to interface with the wiggler are documented and I was 
>able to read and write to ARM7 memory and registers.
>
>If anyone has a better solution to interface with the wiggler without 
>getting into the low level JTAG chain I would be interested in any 
>suggestions.

Look for the project JTAGER on sourceforge. There are other similar
projects as well (ARMTOOL etc.) but JTAGER seems to be actively
developed.

Regards
   Anton Erasmus

erol.benoz@tnn.net (Erol) wrote in news:5e4da3b5.0409071025.5b3770c0
@posting.google.com:

> I bought a wiggler probe for ARM7 and was very disappointed when I
> didn't receive a Flash Programmer Utility with it! Apparently they
> sell the Flash Programmer SW for 500 extra bucks!
> 
> I am not eager to pay any additional dollars to this company,
> so I would like to know if the wiggler can be used with any other
> Flash Programmer software.
> 
> Thanks,
> 
> Erol
> 
> P.S. I heard that the OCD Commander SW can be used to download
> Flash programming SW into target RAM, but I prefer an easier solution
> if possible.

I realise this is an old post but I am about to develop a flash loader
for the STR710 through the Wiggler.

My approach is going to be use OCDLibRemote to set up the TCP server on 
localhost port 8888 and connect to it using a C++ builder application.

I have not developed the download code yet but it only took a few minutes 
to set up a simple test program and connect to the wiggler in this 
manner.

The GDB commands to interface with the wiggler are documented and I was 
able to read and write to ARM7 memory and registers.

If anyone has a better solution to interface with the wiggler without 
getting into the low level JTAG chain I would be interested in any 
suggestions.

"Lewin A.R.W. Edwards" ...
> > What does the $500 tool do? Yes - poke a self-flashing downloader
> > into RAM and run it.
>
> Really?! I was under the impression that it set up the processor's
> memory mapping/chip select registers and then wiggled the ext A/D
> buses directly through the core's JTAG interface. Interesting.

Wiggling the A/D busses and strobing CS and R/W through the JTAG is much too
slow to be useful, you need many JTAG cycles per R/W access. A small loader
that does direct bus writes is much faster.

The flash tool really comes with a bunch of small loader files, one for each
core type, separate for big- and little endian mode etc.

Regards,
Arie de Muynck

On Wed, 08 Sep 2004 01:43:08 -0700, Erol wrote:

> "Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<Ent%c.10408$Wv5.2965@newsread3.news.atl.earthlink.net>...
>> > kinda funny how people on usenet are seeking to just try and show their
>> > 'brilliance' huh............  they don't really give a damn about your
>> 
>> Ah, so you'd rather be generous with stupidity than parsimonious with
>> brilliance? Very humanitarian of you to share your ignorance.
>> 
>> Think about the OP's problem for a moment. What is the wiggler? A debug
>> tool. What do you do with a debug tool (mainly)? Load code into RAM. So
>> in order for the wiggler to be ANY use to him, he must already know how
>> to drive it to load code into RAM, and he must already know how to build
>> code for the target platform.
>> 
>> If it is not worth $500 to him to write a snippet of code to write his
>> particular flash chip, then he can damn well spend the money. What he is
>> asking for is someone here - whose time is probably worth $150 per hour
>> - to give him free consultation so he doesn't have to pay for a
>> ready-rolled solution.
> 
> I just asked if anyone succeeded in using this wiggler with any other
> Flash Programmer SW, is this too much? Does it require a lot of effort
> to answer this? You can still call this "consultation" if you want.
> 
> Of course I can write another 500 lines of code for the flash burner,
> but why i'm here is because i need it now, time is the problem!

you could try the openwince jtag tools here:
http://openwince.sourceforge.net/jtag/

The 0.5.1 version on the web page is pretty old, I would recommend the
version in CVS at sourceforge.net. I have it working with a homebrew
wiggler and some local patches for a Toshiba mips part and a 29LV200
flash. I'm soon to have a 'real' wiggler to test with.

> But my SRAM is not sufficient for the flash image and i think i can't
> upload the image into my SDRAM because the SDRAM controller isn't

You can initialize the SDRAM controller using memory writes initiated
over JTAG. EXACTLY the same way you would debug a running program,
modify its RAM/hardware state, etc.

> What does the $500 tool do? Yes - poke a self-flashing downloader
> into RAM and run it.

Really?! I was under the impression that it set up the processor's
memory mapping/chip select registers and then wiggled the ext A/D
buses directly through the core's JTAG interface. Interesting.

"Erol" ...
> I think the idea is to upload both the flasher and the flash image
> into target RAM and then run the flasher.

Yep.

> But my SRAM is not sufficient for the flash image and i think i can't
> upload the image into my SDRAM because the SDRAM controller isn't
> initialized yet at this upload moment. (Can I first load and run a
> startup code to initialize SDRAM and then load the image into SDRAM?)

You can probably use the gdb.ini file to setup the SDRAM controller
registers. It works fine in our Netsilicon CPU, also with SDRAM.

As David Brown suggested, you can also do it in stages.
You would need to write a small tool to chop up the image and glue it with
some base address info after the flash loader.
Automate the whole loading process with a simple tool (even a batchfile
would do) and the difference is minimal.

> It seems that the most reasonable option is to get the image from the
> RS232 port which i don't have at the moment. If the 500$ wiggler SW
> does the same (loading image first into RAM), maybe it isn't useful
> for me anyway because i don't have enough SRAM for flash image
> storage.

Not sure about that. Ask McGraigor   ;-)

Well, if you can't spare the UART there is still a nice item in the ARM7TDMI
core called the DCC (Debug Communication Channel).
It is a 32-bit register plus some status bits which can be read and written
with very low overhead by the JTAG, and by the ARM core. It is the perfect
(and fastest) communication channel between a PC-based application and a
small flash routine in the ARM code. Complexity on the ARM side is not more
than a UART.
Unfortunately I have no (open source) JTAG driver for our Raven setup, so we
stuck to the flash + image loader combo.

NOTE: If someone has a tool (prefereably readable open source) to use this
channel through a Chameleon or Raven I would be very interested! Wiggler I
could do myself - if time available (it isn't).

Regards,
Arie de Muynck

> Of course I can write another 500 lines of code for the flash burner,

If you need to write 500 lines of code for a system-specific "kiss of
life" RAM-based flashloader, then 400 of them damn well better be
comments.

On Wed, 08 Sep 2004 11:56:00 +0200, Amontec Team
<laurent.gauch@amontecDELETEALLCAPS.com> wrote:

>KO ! We cannot give a complet specific solution since there are lot of 
>different cpu and a lot of different FLASH. Note this is why a FLASH 
>uploader is cheap at $500...

Only if you, as a customer, need to support a "lot of different FLASH."  If you
only need just the one supported, then all that extra baggage is just ...
baggage.

The value in having a complete solution for many cases is that it is valuable to
the competition also trying to develop similarly complete solutions, and not
nearly so much to customers with only one problem to solve.

Just a penny note,
Jon

>
> I think the idea is to upload both the flasher and the flash image
> into target RAM and then run the flasher.
>
> But my SRAM is not sufficient for the flash image and i think i can't
> upload the image into my SDRAM because the SDRAM controller isn't
> initialized yet at this upload moment. (Can I first load and run a
> startup code to initialize SDRAM and then load the image into SDRAM?)
>

The usual way for flash loader programs to work is by first uploading a
flash burner program to ram.  Then the target program is uploaded in batches
into a buffer.  After each batch is uploaded, a routine in the flash loader
program is called to program in that buffer-full, ending in a breakpoint to
return control to the debugger.  That way, the whole flash can be programmed
even if only a small internal ram is available.


> It seems that the most reasonable option is to get the image from the
> RS232 port which i don't have at the moment. If the 500$ wiggler SW
> does the same (loading image first into RAM), maybe it isn't useful
> for me anyway because i don't have enough SRAM for flash image
> storage.
>
> thanks,
> erol