• AVR Freaks

Hot!@ Operator corrupts whole program

Author
werner
Starting Member
  • Total Posts : 66
  • Reward points : 0
  • Joined: 2003/11/07 12:38:58
  • Status: offline
2019/09/05 00:06:23 (permalink)
0

@ Operator corrupts whole program

I have a Project with 18F47K42 V2.10 and more than 64k. Everything worked fine until I changed following line:
const char Version[] = "V1.23";
to
const char Version[] @ 0x100 = "V1.23";
(I need a fix adress for reading it from Bootloader)
After setting this, many outputs of text strings don't work anymore! I have a big struct with a lot of texts for several languages.
Any idea, what happens ?
Werner
#1

7 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3059
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 02:34:37 (permalink)
    +1 (1)
    The above being the only modification?
    Might help to compare the map files with/without this modification.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    ric
    Super Member
    • Total Posts : 23839
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 02:45:51 (permalink)
    +1 (1)
    Hmm, sounds like the "NVRAM" errata for the K40 devices, but you have a K42.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    du00000001
    Just Some Member
    • Total Posts : 3059
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 03:23:42 (permalink)
    0
    I've had the same thought.
    Setting the Errata option to "all" wouldn't hurt anyway.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #4
    werner
    Starting Member
    • Total Posts : 66
    • Reward points : 0
    • Joined: 2003/11/07 12:38:58
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 05:05:49 (permalink)
    0
    Yes, it is the only changing.
    Trying +NVMREG doesn't change anything.
    Comparing the map files is hard, because there are 1000 of changes. Interesting is that some functions are using more ram.
     
    But anyway, I don't have the time to analyse it further ! So I will avoid using this operator completly.
     
    Thanks
    Werner
    #5
    davekw7x
    Entropy++
    • Total Posts : 1827
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Second star on the right, straight on till morning
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 09:54:07 (permalink)
    +2 (2)
    werner

    const char Version[] @ 0x100 = "V1.23";

    (I need a fix adress for reading it from Bootloader)



    I am assuming:


    • This is the application version.  It will change from time to time.  The bootloader needs to read it for whater reason.
    • Your bootloader resides in low memory (starting at zero)
    • Your application code is located above boot memory (probably using Codeoffset).
    • The bootloader is an MPLABX "Loadable" in the application project.

    If any of these is not true, then tell us how your project is organized.

    If all of those statements are true, here's my take on it:

    Do NOT put things that change when you recompile the application code in boot memory.

    Why?  Well:
    1. You do NOT want to have the bootloader try to load stuff in boot memory when the bootloader is running.  Even if you could do this, by hook or crook, you simply don't want to do it.  Once the bootloader is in place it stays untouched by application code uploads.  Forever.
    2. Once the product is released into the wild, you do NOT want to recompile the bootloader.  Not ever.

    Therefore, for application-specific information that the bootloader needs to access:
    • Put the application-specific information in a fixed location (using @ or __at() in the application source) above boot memory and make a definition in the bootloader source that allows the bootloader to access that memory.
    • If you put it in the application code area just make sure it is not in a place that is needed by reset or interrupt vectors.
    Have done this for a number of bootloadable applications over the years.

    Regards,

    Dave


    post edited by davekw7x - 2019/09/05 10:15:15

    Sometimes I just can't help myself...
    #6
    1and0
    Access is Denied
    • Total Posts : 9734
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: online
    Re: @ Operator corrupts whole program 2019/09/05 10:18:38 (permalink)
    0
    What about storing it in the UserID Locations?
    #7
    werner
    Starting Member
    • Total Posts : 66
    • Reward points : 0
    • Joined: 2003/11/07 12:38:58
    • Status: offline
    Re: @ Operator corrupts whole program 2019/09/05 23:49:15 (permalink)
    0
    @Dave
    Error occurs also in debug configration:
    - no Code offset
    - not loading the bootloader
    - Boot block disabled
     
    @1and0
    Yes UserID is one Option, I choosed EEPROM
    #8
    Jump to:
    © 2019 APG vNext Commercial Version 4.5