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