duane> What is the required work area size?
rick> None. The flash methods ....
Actually the flash methods do need space - otherwise they will not work.
Thank you for pointing out the flash - I had forgotten about that.
There are two sides to the problem.
(A) flash programing - I had forgotten. Happens, but not as frequently.
(B) General GDB downloading: Happens all the time.
I dug around a little... and this is what I found.
-Duane.
DCC download requires 24 bytes.
Poking around the flash code I see this:
ie: LPC2000 I see something 172 bytes needed
I see stuff in the CFI Intel flash code talking about 1K bytes.
All FLASH code has the same copy/paste loop that wants something more
then 256 bytes
================================
Based on my read of the code:
I think this would be "good manual/documentation policy"
(A) From a *manual* point of view.
Flash programing requires at least :
1K ram for micro-controllers (internal flash)
2K ram for any external flash.
For *large* system on a chip solutions - 2K is enough
However we recommend 4K on systems with SDRAM.
(B) From a *manual* point of view..
We tell users:
If at all possible - dedicate a N-Byte region for the DCC.
Today N = 24 bytes, but think future.
Should the manual say 64 bytes - or 128 bytes?
And use the extra bytes for data abort capturing (if needed)
(C) FUTURE:
Maybe we even create a "-dcc-work-area" target option?
It would always be backed up and restored ..
And - it needs to be smart about GDB loading over the top of it.
Maybe we create a "-flash-work-area" target option?
Today - existing OpenOCD code treats "work area as work area"
generically.
(D) On chips like ARM 9 - that have Vector Catch.
Vector Catch should be enabled during this period.
And "restored to previous state" when done.
Perhaps this should be on any time "run algorithm" is used.
(E) Not sure about Vector Catch on Arm7.
Not familiar enough with arm11 and cortex variants.
(F) Some places for work could be:
Improve the flash algorithms to "ping-pong"buffers
ie: Instead of polling the flash for completion
Start downloading the next sector.
=======
**END**
=======
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
