Re: CW Real Time Simulator Memory Window Shows Stale Values

[eric_cina]

Thanks Gilles. Worked like a charm. I guess I should read those
release notes, although there are quite a few of them. Thanks for
the help.

Regards,
Eric

--- In [hidden email], Gilles Blanquin
<gilles.blanquin@f...> wrote:
> Hi Eric.
>
> If you have installed the ICD12 USB 2.0 Service Pack
> ("CW12_V3_1_ICD12_USB2_0_Sim_patch.exe"), please have a look in
the release
> note installed in:
>
> {CW install path}\Release_Notes\HC12\CW_Tools\HC12
\Notes_debugger_icd12.txt
>
> The debugger has been improved to cache all chip memory accesses
that can
> be considered as "non volatile", this avoiding reading identical
data for
> no reason, on flow rebuild, memory display, etc.
>
> Of course, when the flash is intended to be reprogrammed by the
user
> application, it would be better to disable this option.
> The ICD-12 "Debug Memory Map" menu entry opens the Debugging
Memory Map dialog.
> Blocks like Flash block can then be modified as here below,
> changing/checking the "refresh memory when halting" option to make
sure the
> caching is disabled.
> This setup is saved in the current project.
>
> The "releasecache" command is available to clear occasionally the
caches

> also for module having this option disabled.
>
> Regards,
> Gilles
>
> (Release Note Extract here below)
>
> 3-Debugging Memory Map dialog and Manager
> -----------------------------------------
> The Debugging Memory Map dialog user interface replaces

the "banked Memory
> Location" dialog
> ("Set Bank..." menu entry). This interface provides a global
approach for
> all different
> CPU families, each family having its own method for memory access
and its
> own memory
> onchip layout and memory module priorities.
> By the way, the "BANKWINDOW" command has been completely removed,
as banks
> handling is
> now transparently handled by the Debugging Memory Map Manager. In
case of
> error due to this
> command execution, please remove/comment this command. In case of
any
> further debugging problem
> due to this command removal, please contact Metrowerks support
team.
>
> The graphical user interface is flexible enough to be handled
without much
> text description
> here, and live diagnostic is displayed within the dialog. Anytime,
it is
> possible to revert
> to default (factory) setup, and most of the time, the user does
not need to
> edit/change settings
> within this dialog.
>
> Functionalities:
>
> -Pressing "New" button will create a new module, and open directly
the
> edition dialog to
>   setup this new module.
> -Pressing "Modify" opens the edition dialog of the selected module
in list.
>   More module information are displayed here, and an enhanced
diagnostic is
> also displayed.
> -Pressing "Delete" button will lead to module removing, after a
warning dialog.
> -Pressing "Revert to default" will remove the current setup
(usually saved
> into current project)
>   and retrieve the default (factory) setup for an internal
database.
>
> Module edition:
>
> -"Enable memory module" options maps the module in the debugger.
Unchecking
> this option
>   makes the module completely "transparent" for the debugger.
> -The "Type" drop down list provides all kinds of memory type
available for
> this processor.
> -The "Priority" drop down list provides all kinds of memory
overlap
> priority available
>   for this processor. The debugger can have a bigger priority
("highest")
> to setup an upper
>   module that can overlap an onchip module, this to make a display
filter,
> e.g. creating
>   an "no read access while running" memory range.
> -The "Refresh memory when halting" option controls debugger memory
cache.
> When this option
>   is checked, internal image/cache of memory data are always
deleted and
> the data is always
>   retrieved from hardware when required by the debugger. When
unchecked
> (usually by default
>   for Non Volatile Memory areas) the debugger keeps a copy of the
data and
> does not retrieve
>   the data from hardware until next application
loading/programming.
> -The "no memory access while running" option can be used to
discard
> debugger access to a
>   memory range which can regularly be accessed while running. This
feature
> is useful to protect
>   onchip register flags from being triggered by debugger reads.
>
> Remark:
>
> -Modules range/boundary are always limited to an overlapped module
with a
> bigger priority.
>   For example, if 2 bytes have been defined in a module which
overlaps
> another module, accessing
>   these 2 bytes will be performed using the 2-byte module
properties.
>   The memory on both sides of these 2 bytes will be accessed using
the
> overlapped module properties.
>
>
>
> At 07:37 PM 6/7/2005, you wrote:
> >Hi,
> >
> >I am writing and debugging my own routines to program and erase
the
> >flash on my E128 board. They work ok but sometimes they appear not
> >to work. I say 'appear' because I think CodeWarrior is playing
> >tricks on me. If I set the Memory Window to view a location in
flash
> >(say 3AA000 for example) and I use my firmware to write or erase
> >that location, the Memory Window does not display this change.
Even
> >if I change locations and come back, hit run and stop,
whatever...it

> >doesn't update.
> >
> >I use my own routine to read the flash and it gives me the value I
> >expect everytime.
> >
> >How do I get the Memory Window to update its values? It is showing
> >stale values right now and it is very deceiving.
> >
> >Thanks in advance.
> >
> >Regards,
> >Eric
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/