Question about memory readback JLink and GDB

  • Question about memory readback JLink and GDB

    Hi,

    If the code is changing some flash area, because it uses that as an eeprom, I can't see the changes with GDB. I'm sure that the code is changed because I can see this with the webserver (the application of the embedded device).

    I can see in the JLink log window that the memory is actually transferred from JLink to GDB.
    Is this a GDB problem or is JLink caching and is giving the old content (flash breakpoint implementation perhaps???).

    My network spy isn't working because this is happening all local, but perhaps this is something obvious what I'm missing here.

    Update:
    If I read the memory positions back with "monitor memu32" I also get the old memory content back. Perhaps JLink caching after all????

    And I'm sure that the content is changed. If I reset and break at the checksum calculation which is used to check the eeprom, I can see that everything is there.

    The post was edited 1 time, last by EmBlocks ().

  • Hi emBlocks,

    you are right, per default, flash memory is treated as fully cacheable, and it does not get invalidated when the CPU runs.
    We have a functionality to not cache it or to invalidate a certain part of it (the part that one would use for data storage).
    The settings are stored in the settings file (Control panel).
    However, the best way would probably be a monitor command that does the same thing and allows automatic
    invalidation of the flash area or a part of it. I guess we will implement this functionality next week.

    Will keep you posted. Happy Easter :)
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Rolf wrote:

    However, the best way would probably be a monitor command that does the same thing and allows automatic
    invalidation of the flash area or a part of it. I guess we will implement this functionality next week.


    Yes, that would be nice. The base address with the length, perhaps possible on multiple sections.
    I will make an additional tab at the JLink settings dialog where non-cacheable regions can be specified.

    Yes, also a happy Easter :thumbup: .
  • Hi EmBlocks,

    The base address with the length

    That's the way it will be implemented :)

    perhaps possible on multiple sections

    First implementation will allow a single region only. This might be extended in the future by allowing multiple ones.

    Keep you posted regarding the availability of this feature.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Alex, thanks for the update.

    Is it very difficult to support this for multiple regions? or is this a matter of time.
    I can imagine if you can do it for one you can do it for 'x', but that's just my simple approach :whistling: .

    Regards
  • Hi EmBlocks,

    Is it very difficult to support this for multiple regions? or is this a matter of time.

    More the second. For now, the first implementation will support 1 range (which should be sufficient in most cases).


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.