• AVR Freaks

Hot!18F14K50 Reading Memory Locations and Testing Them

Author
kjo
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2006/07/11 15:11:02
  • Location: 0
  • Status: offline
2020/08/13 14:58:22 (permalink)
0

18F14K50 Reading Memory Locations and Testing Them

I have a USB application that can be loaded native or by using a bootloader. I want the PC side to know whether the PIC application is a BL version or native. On the 14K50 location 0x001C is to bootloader vector. W/O a bootloader it is a NOP (F023) and if the bootloader is present it is a GOTO (0xEF18).
 
I have tried several methods to read and test the value of this location but always it is 0.
 
    char bl_stateval = *(char *)0x001C;

    if(bl_stateval == 0xF023) {IsBL_Version = 0;}
    if(bl_stateval == 0xEF18) {IsBL_Version = 1;}

 
is error free but bl_stateval is always 0.
I have confirmet that the expected values in address 0x001C are correct by inspection of hex code.
 
I tried some other pointer forms but get "illegal pointer / integer conversion warnings.
 
There has to be a simple way to do this that I am missing.
 
#1

14 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 15:11:02 (permalink)
    +2 (2)
    Your bl_stateval points to RAM while you neea pointer to flash !
    Check what the definition of a flash (ROM - aka "const") pointer has to look like!

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 15:25:17 (permalink)
    +2 (2)
    This is why there are always big warnings about trying to convert integers into pointers.
    This becomes especially relevant when you are working in a Harvard Architecture device like a PIC, where ROM and RAM (aka code and data) occupy independant address spaces.
    https://en.wikipedia.org/wiki/Harvard_architecture
     
     

    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
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 15:32:58 (permalink)
    0
    @du*1
    Duh.... So obvious when pointed out!
    Be back soon...
    #4
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 16:12:01 (permalink)
    0
    @du*1
     
    For others...
    Just a matter of understanding the data types and applying them correctly!
     
        unsigned short bl_state = *(const unsigned short *)0x001C;

     
    Left side is 16 bit unsigned variable.
    Right side points to low byte of a requested 2-byte word 0x001D:0x001C in ROM (flash)
     
    QED with help!
    post edited by kjo - 2020/08/13 16:13:15
    #5
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 16:28:32 (permalink)
    +2 (2)
    Couldn't you just read it directly with this declaration?
    const unsigned short bl_state __at(0x01C);

     
    (I was going to suggest this form, but "volatile" is only needed if the ROM value can change while your code is running, and "extern" shouldn't be required if it's not initialised)
    extern const volatile unsigned short bl_state __at(0x01C);


    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!
    #6
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 16:41:36 (permalink)
    0
    Very likely...
    Soo many ways to to say the same thing. I don't recall using __at() before.
    I wonder if the compiler reduces both to the same code?
     
    edit:
    Yes first form works just fine.
     
    post edited by kjo - 2020/08/13 16:44:03
    #7
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 16:48:03 (permalink)
    +1 (1)
    kjoconnor
    I wonder if the compiler reduces both to the same code?

    Your version appears to use an extra copy in RAM. I'm not sure if that would get optimised away.

    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!
    #8
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/13 18:13:16 (permalink)
    +1 (1)
    kjoconnor
    Very likely...
    Soo many ways to to say the same thing. I don't recall using __at() before.
    I wonder if the compiler reduces both to the same code?
     
    edit:
    Yes first form works just fine.



    There are many ways to skin a cat  grin: grin
    Not sure about the aspects of optimization...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/15 07:11:54 (permalink)
    0
    ric
    Couldn't you just read it directly with this declaration?
    const unsigned short bl_state __at(0x01C);

     
    (I was going to suggest this form, but "volatile" is only needed if the ROM value can change while your code is running, and "extern" shouldn't be required if it's not initialised)
    extern const volatile unsigned short bl_state __at(0x01C);



    After working with both my form and ric’s first form for a while I am finding that there is an occasional subtle difference. While my form seems to fetch the correct ROM contents under the tested conditions, the “__at(address) form periodically fetches the incorrect data. 
    I am not quite sure what is going on, but the error seems to occur when first attaching to the USB bus. At enumeration time I read that ROM address as part of the initialization sequence. Sometimes it is incorrect, (maybe always). Subsequent reads of that address appear correct. It is odd. 
    I need to do some more consistent tests but I thought it worth reporting.
    Also, when did the “__at()” arrive in this rendition of C? 
    #10
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/15 10:57:57 (permalink)
    0
    Using
    const unsigned short bl_state __at(0x01C);

    I do get a warning “local variable _bl_state cannot be made absolute.
    #11
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/15 15:51:55 (permalink)
    +1 (3)
    kjoconnor
    Using
    const unsigned short bl_state __at(0x01C);

    I do get a warning “local variable _bl_state cannot be made absolute.

    As the message says, it can't be a local variable.
    Move the definition outside the function to make it global.

    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!
    #12
    Jerry Messina
    Super Member
    • Total Posts : 550
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/16 05:23:36 (permalink)
    +2 (2)
    While my form seems to fetch the correct ROM contents under the tested conditions, the “__at(address) form periodically fetches the incorrect data.

    There is a difference between how/when the two forms read the flash.
     
    In the first form, the read is done as an initializer so it sets bl_state once when the initializer "runs".
    In the second form using '__at', bl_state will be read when the variable is actually used, ie "if bl_state == xxx".
     
    Both forms would involve setting the TBLPTR registers and reading TABLAT, but the second one will be doing it "on the fly" which might cause issues with interrupts.
     
    Is the USB stack set for polled or interrupt mode?
     
     
     
     
    #13
    kjo
    Junior Member
    • Total Posts : 94
    • Reward points : 0
    • Joined: 2006/07/11 15:11:02
    • Location: 0
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/18 08:50:03 (permalink)
    0
    @ric
    So true...  But why should it throw that warning in the first place? I can certainly initialize such a variable in main.
    What is it about _at() that requires a global variable?
     
    @jerry
    I'm using an interrupt driven stack full speed. Of course that was the recommended default in the MLA.
    Your comment may explain the observation. Since my purpose is simply for the application to be aware
    of whether it is a bootloaded or native version, static initialize time is fine and likely better.
    #14
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: 18F14K50 Reading Memory Locations and Testing Them 2020/08/18 13:42:42 (permalink)
    +2 (2)
    kjoconnor
    What is it about _at() that requires a global variable?

    It is declaring something that applies to the entire life if your program (an absolute address), so it can't be local.
     

    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!
    #15
    Jump to:
    © 2020 APG vNext Commercial Version 4.5