On Fri, May 02, 2014 at 07:56:43AM -0700, Duane Ellis wrote:
> Paul>> What do you think, do you see any downsides with this?
>
> Concerns:
>
> a) Masked rom - is not flash - how do you specify that range?
> Example: Many M3s have a small masked rom ‘boot loader’ you want to
> step through and debug.
>
> b) A target that FLASH programming is not supported by opened, thus
> you program the FLASH by other means …
>
> c) A target where something else {example: boot loader, or band-boot
> hardware} loads a stub into CODE ram - and you need to treat that
> area as a “pseudo rom’.
All three cases can be covered by a trivial "rom" (flash/nor) driver
it seems.
> As for an implementation method, the closest function is:
> get_flash_bank_by_address() -
>
> Issues with using that function
>
> Concern (above-A) The related area might not have a flash bank structure
> over that area.
Yep, but trivially solveable.
> Concern (new) - we don’t want to “probe” the flash area when we are
> determining breakpoint type.
Why not force auto-probing there? It'll happen just once, many targets
do not even require to be halted for probing (and for those that do,
user can be told so).
> Could write a new function - something like: flash_IsThisAddressInFlash(
> target_pointer, ADDRESS ) this would *NOT* probe anything
> Do you see a problem with assuming the “flash address range” is always valid
> if not auto-probed?
Yes, many flash drivers populate it only during probe time. But,
again, I do not see any issues with requiring auto-probing there.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[email protected]
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
