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

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.

Reply to
Erol
Loading thread data ...

"Erol" ...

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.

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

Reply to
Arie de Muynck

The $500 for a Flash upload SW is cheap enough for the JOB ! Just try to write your own SW to do the same JOB ... You will spend days and money too !

But if you still don't want to buy specific SW, your only solution will be to write C code function doing a RAM to Flash copy. Then put and call your function in your own ARM7 firmware. Then use OCD with a Wiggler/Raven JTAG interface to upload all your code ... Not easy to do the first time, but this step has the big advantage for you to understand many things concerning the ARM7 architecture and concerning your specific and custom ARM7 platfrom too.

Note: Chameleon POD is from

formatting link

Larry

Reply to
Laurent Gauch

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.

Sorry, i have never done ARMs, or the wiggler......... i would help you if i could....

Reply to
George

The easier solution is to buy the $500 tool. But the _usual_ way impoverished people like me use the wiggler is to poke a self-flashing bootloader into RAM.

Reply to
Lewin A.R.W. Edwards

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.

Reply to
Lewin A.R.W. Edwards

"George" ...

if

I do help - as far as I can without giving away code paid for by my employer. If this advice is not enough for him he should not be designing this part of a project - unless he wants to learn. This is usenet - not a shopping mall.

YOU did not provide any help at all. Kinda funny how people on usenet are seeking to just try and show their 'higher standards' huh............

Regards, Arie de Muynck

Reply to
Arie de Muynck

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

Just bite the bullet, write a programmer for your flash, download it together with the target code, and program.

An example:

I'm using an Atmel AT91R40008 with 256 kbytes of RAM at 0. The programming sequence is:

  1. Write proper chip select to CS0,
  2. Write remap cancel to EBI,
  3. Write address range selection to EBI,
  4. Download flash writer at 0x3c000
  5. Download target code at 0x2000
  6. Patch the target code location and length to writer
  7. Start the writer.

That's it.

Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

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!

Reply to
Erol

Arie, thank you for the encouragement! Can the flasher code i'm going to write download the Flash image from the JTAG interface? I didnt use this interface from my target SW before. I dont have a working RS232 port on the board yet, do i need RS232 for the flash image download?

Reply to
Erol

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 !

Reply to
Amontec Team

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

Reply to
Erol

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.

Reply to
David Brown

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

Reply to
Jonathan Kirwan

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.

Reply to
Lewin A.R.W. Edwards

"Erol" ...

Yep.

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.

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

Reply to
Arie de Muynck

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.

Reply to
Lewin A.R.W. Edwards

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.

Reply to
Lewin A.R.W. Edwards

you could try the openwince jtag tools here:

formatting link

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.

Reply to
Andrew Dyer

snipped-for-privacy@tnn.net (Erol) wrote in news:5e4da3b5.0409071025.5b3770c0 @posting.google.com:

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.

Reply to
DirtyOldMan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.