how to program a flash with the wiggler? (for free)

George wrote:
> 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
> problem, or your solution, just wanting to show their ass..  and you never
> really get an answer to the question posed.

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...

We work for money ... not just for fun !
After working, FISHING !

"Arie de Muynck" <Sorry_I_hate_spam@nomail.com> wrote in message news:<413e0ce6$0$21106$e4fe514c@news.xs4all.nl>...
> "Erol" ...
> > 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.
> 
> Hihi, we also fell for it. The 500$ flash SW is also locked to one PC. And
> didn't program our NetSilicon chips. Money lost.
> 
> > 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.
> 
> It's really the best method. Just two pages of C-code did the trick. You
> need minimum startup code until main, then a flash erase / programming /
> verify routine that burns a binary image, linked with the flasher code, into
> the flash chip. Runs in our production now without problems.
> 
> (We use a Jeeni to upload code to RAM, much faster than Wiggler or Raven or
> the low cost Chameleon pod, a good Wiggler / Raven / etc. emulator.)
> 
> Regards,
> Arie de Muijnck

Thanks Arie and Tauno, 

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?)

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

>
> 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

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

> 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.

"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

> 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.

> 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.

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.

"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