• AVR Freaks

eeprom initialization using de directive

Author
dj41354
Starting Member
  • Total Posts : 40
  • Reward points : 0
  • Joined: 2011/03/02 10:25:21
  • Location: 0
  • Status: offline
2018/09/10 16:24:49 (permalink)
0

eeprom initialization using de directive

MPLABv8.86 assembly using MPASM on the PIC18F46K22
I added a section to my project containing multiple "de" directives to clear the 1st 256 bytes of eeprom to zero when I program the device using either my ICD3 or PM3. I noticed that when I added the section containing the "de" directives and re-built the project that the new "hex" file was EXACTLY the same as the "hex" file before adding the new section.. is this right? How does this work when the "hex" file is what I give out to have my new parts made that I want with eeprom cleared?
Thanks in advance!
DougJ
#1

8 Replies Related Threads

    qhb
    Superb Member
    • Total Posts : 9999
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/10 16:33:26 (permalink)
    0
    Did you look in the hex file to see if the data is actually there?
    The format is well documented, see: https://en.wikipedia.org/wiki/Intel_HEX
    Maybe it defaults to zero even if you don't specify it.

    Nearly there...
    #2
    dj41354
    Starting Member
    • Total Posts : 40
    • Reward points : 0
    • Joined: 2011/03/02 10:25:21
    • Location: 0
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 06:26:43 (permalink)
    0
    Yeah I looked, not there. There's definitely some weirdness afoot.. I had "INCLUDED" the data section that had the "de" directives in one of the projects source files, but for some reason, MPLAB wasn't "including" it (knew this cause I renamed the file with the "de" directives only, without re-naming the line where I "INCLUDED" it, and MPLAB re-built the project with no errors).
     
    So took another approach and made a separate stand-alone source file with the "de" directives and added the file to the project. When I rebuilt I gott a linker error:
      "Error - section '.org_0' type is non-overlay and absolute but occurs in more than one input file."
     
    I went back again to the 1st approach tried to "INCLUDE" just the "de" directives in a couple of the other source files in the project, and at least can get that same linker error.
     
    It seems the linker doesn't like the "org 0xF00000" directive that precedes the "de  0,0,0,0,0,0,0,0" directive.. 
    I do have some other source files with "org" directives, like the bootloader needs to be in a specific place, and there are a few other files with orgs.. but I don't quite understand what the linker is complaining about??
     
    Thanks for any help with this..
    DougJ 
    #3
    qhb
    Superb Member
    • Total Posts : 9999
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 06:55:24 (permalink)
    0
    Do you know the difference between absolute mode and relocatable mode?
    It sounds like you have a mix of both in the same project.
     

    Nearly there...
    #4
    NorthGuy
    Super Member
    • Total Posts : 5665
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: online
    Re: eeprom initialization using de directive 2018/09/11 07:06:15 (permalink)
    0
    EEPROM doesn't have a memory-mapped location on this PIC. The designated HEX file location is 0xf00000, but most other PIC18s use 0x310000. Most likely, you have encountered a bug where some of the toolchain parts (compiler/linker/programmer/documentation) think it's 0xf00000 while others think it's 0x310000.
    #5
    dj41354
    Starting Member
    • Total Posts : 40
    • Reward points : 0
    • Joined: 2011/03/02 10:25:21
    • Location: 0
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 07:37:55 (permalink)
    0
    qhb
    Do you know the difference between absolute mode and relocatable mode?
    It sounds like you have a mix of both in the same project.
     


    I understand the concepts, but have always been unclear on what the settings mean to MPLAB, and how those settings affect how source files should be constructed. Throughout my career on a variety of assembly tools, I've used "org" to tell an assembler/linker I want this code to go to a specific location (absolute), and if I don't "org" it, I don't care where it goes (relocatable). I guess I've always thought assembly language linkers are smart enough to figure out how to nest relocatable sections around the absolute sections.
     
    It's not uncommon that I care about some sections, and don't care about others.. so I guess it's fair to say I have a mix.. I've had trouble with the "absolute" and "relocatable" MPLAB setting in the past , so my approach has been to not select one, and do whatever I need to do with the source files to make it work.. not a great answer, but there it is..
     
    What would be the "correct" way to have a mix of absolute and re-locatable code segments in MPLAB?
     
    Thanks for your help with this..
    DougJ 
     
     
    #6
    1and0
    Access is Denied
    • Total Posts : 9728
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 08:05:30 (permalink)
    0
    dj41354
     
    I understand the concepts, but have always been unclear on what the settings mean to MPLAB, and how those settings affect how source files should be constructed. Throughout my career on a variety of assembly tools, I've used "org" to tell an assembler/linker I want this code to go to a specific location (absolute), and if I don't "org" it, I don't care where it goes (relocatable). I guess I've always thought assembly language linkers are smart enough to figure out how to nest relocatable sections around the absolute sections.

    It is not section, but whether it is the mode in which the assembler operates. In a nutshell, absolute mode uses ORG directive to specify absolute program memory address and CBLOCK/ENDC (or the less preferred EQU) directive to define variables symbols to absolute addresses; while relocatable mode uses CODE directive to specify program memory sections to either absolute or relocatable address, and the various UDATA directives and RES directive to reserve variables to either absolute or relocatable address.  And you cannot mix them in the same project.
     
    I could try to use my crystal ball to see your errors, but I whether to see you code instead. So post a minimal build-able source code that demonstrates the problem, and you will get your answer quicker.



    #7
    dj41354
    Starting Member
    • Total Posts : 40
    • Reward points : 0
    • Joined: 2011/03/02 10:25:21
    • Location: 0
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 09:07:27 (permalink)
    0
    It feels like I should be able understand this before resorting building a minimal version of it..
     
    I went back and looked at all the source files and can shed some specific light on their constructions..
    All my source files use the "code" directive preceding the code. Some use the "code 0x0100" format to locate them.
    One (and only one) contains an "org" in the middle of it, to locate a jump vector that's necessary for bootloader compatability when bootloading new firmware onto really old units with an old bootloader that jumps to very specific address when done bootloading.. It seems to be this single "org" in this one source file that makes the "de" directive (along with the prerequisite org 0xF00000 for the eeprom locations) fail.
     
    In my head, it seems like the eeprom data definition scheme should be tolerant to whatever my code is in a similar way that ram data definition is tolerant to code, but I guess not. I'm guessing that it's that I have two "org"s in my project that is the problem, even though one is for data generation and one is for code generation.
     
    I re-built the project without the "org" in the one code section that had it.. it built fine. I then added the new eeprom definition section, with the "de" and "org 0xF00000" directives, and it's all good. The hex file now shows the new data located at "0xF00000" that's used to initialize the eeprom when the part is programmed.
    Maybe I just need to bite the bullet and forget about being able to bootload onto the really old units that need that specific address to jump to when bootloading is done. I can probably also carve up that one section that has the "org" in it, it's the single largest code section in the project, and put the jump vector in it's own section with the "code 0x0100" directive to locate it.
     
    The one question I still have is how is.. how is all this affected by the MPLAB IDE "project"/"build options"/MPASM/C17/C18 Suite" Tab where under "Single File Assembly Projects" you can select "Generate absolute code" or "Generate relocatable code" or select neither (default?) "Ask me". What do these selections do? and is there a reason to ever select "Generate absolute code" or "Generate relocatable code" in the MPLAB IDE? 
     
    Thanks again very much for the help!
    DougJ   
    #8
    1and0
    Access is Denied
    • Total Posts : 9728
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: eeprom initialization using de directive 2018/09/11 09:18:19 (permalink)
    0
    If you're using the CODE directive, then you are using relocatable mode.  So replace those two ORG directives with CODE directive, and select "Generate relocatable code".
     
    That tab is for you to select which mode you want to use.
    #9
    Jump to:
    © 2019 APG vNext Commercial Version 4.5