• AVR Freaks

Hot!EEPROM write time in Q parts

Author
Andy123
Super Member
  • Total Posts : 618
  • Reward points : 0
  • Joined: 2005/04/25 14:20:54
  • Status: offline
2020/03/24 07:45:47 (permalink)
4.5 (2)

EEPROM write time in Q parts

We have converted our 27K40 based code to Q10 and Q43 parts.
While most of this went smooth, writing to the memory is the challenge.

I have posted few different relevant threads.

Here is a new issue that I see and I think this is beneficial for people to see:
My application is writing calibration data - 152 bytes
For K40 part it takes 418 ms or 2.75ms per byte

For Q10 and Q43 parts it takes 1546 ms. This is 10.17ms per byte.
This is within the specification (11ms max).

So if you are converting your application to Qxx parts, you need to be aware.
Any thoughts?
#1

13 Replies Related Threads

    sdn_
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2020/03/08 02:14:28
    • Location: 0
    • Status: offline
    Re: EEPROM write time in Q parts 2020/03/24 09:32:53 (permalink)
    0
    MEM24 TD_BEW Byte Erase and Write Cycle Time — — 11 ms
    minimum and average values are not indicated.
    post edited by sdn_ - 2020/03/24 09:34:27
    #2
    Andy123
    Super Member
    • Total Posts : 618
    • Reward points : 0
    • Joined: 2005/04/25 14:20:54
    • Status: offline
    Re: EEPROM write time in Q parts 2020/03/24 10:02:24 (permalink)
    +1 (1)
    I am aware of 11 ms, I have posted this in my original post.
    I was trying to bring attention to other users that actual performance is almost 4 times slower than K40
    #3
    davea
    Super Member
    • Total Posts : 247
    • Reward points : 0
    • Joined: 2016/01/28 13:12:13
    • Location: Tampa Bay FL USA
    • Status: offline
    Re: EEPROM write time in Q parts 2020/03/24 12:44:05 (permalink)
    0
    I think you should consider how often cal data changes
    and if less then 10,000 times in the product life time
    use
    10.1 PFM - Program Flash Memory
    [lang="ja"][lang="ja"]The Program Flash Memory is readable, writable, and erasable during normal operation over the entire V[lang="ja"][lang="ja"]DD [lang="ja"][lang="ja"]range.
    A read from program memory is executed either one word, one byte, or a 128-word page at a time. A program
    memory erase is executed on a 128-word page at a time. A Bulk Erase operation cannot be issued from user code. A
    write to program memory can be executed as either 1 or 128 words at a time.
    Writing or erasing program memory will cease instruction fetches until the operation is complete. The program
    memory cannot be accessed during the write or erase, therefore, code cannot execute. An internal programming
    timer controls the write time of program memory writes and erases.
    A value written to program memory does not need to be a valid instruction. Executing a program memory location
    that forms an invalid instruction results in a .
    It is important to understand the PFM memory structure for erase and programming operations. Program memory
    word size is 16 bits wide. A 128-word PFM page is the only size that can be erased by user software.
    create a shadow buffer, copy flash data in to it
    make any changes then write it back (very fast)
    #4
    Andy123
    Super Member
    • Total Posts : 618
    • Reward points : 0
    • Joined: 2005/04/25 14:20:54
    • Status: offline
    Re: EEPROM write time in Q parts 2020/03/24 13:36:36 (permalink)
    0
    Thank you for idea, I just can’t see how we can exceed 10K, even 1000.
    So it may work.

    What I am actually looking is to break 152 byte structure into smaller chunks writing only what is actually changed.
    There are at least 4 definitive sections that can be separated.

    Another approach is not to wait for write to complete.
    I believe EEPROM write operation can be done in parallel with code scanning.
    I see that it may be problematic in some cases...
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 18797
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: EEPROM write time in Q parts 2020/03/24 14:22:59 (permalink)
    +2 (2)
    to save time you would check to see if the EEPROM is busy at the beginning of the Write, not the End.  This allows code to execute while the write is progressing.
    #6
    ric
    Super Member
    • Total Posts : 27697
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: EEPROM write time in Q parts 2020/03/24 14:25:00 (permalink)
    +3 (3)
    +1,  but if you do, you need to add the "is write complete" wait to your erase and read functions too.
     

    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!
    #7
    Andy123
    Super Member
    • Total Posts : 618
    • Reward points : 0
    • Joined: 2005/04/25 14:20:54
    • Status: offline
    Re: EEPROM write time in Q parts 2020/03/24 14:34:43 (permalink)
    0
    Great ideas. I hope it will help other users too. Thank you
    #8
    Andy123
    Super Member
    • Total Posts : 618
    • Reward points : 0
    • Joined: 2005/04/25 14:20:54
    • Status: offline
    Re: EEPROM write time in Q parts 2020/04/02 18:53:38 (permalink)
    0
    I probably should ask in XC8 forum, but this is related to this thread, so let me try:
    Instead of using EEPROM I am looking to use Storage Area Flash (SAF) that is defined as the last block of flash (128 words).
    Is SAFEN is set, then no code can be executed from that area, But what I see is that compiler puts some code there.
    I can increase my reserved storage size from 152 bytes to 256 adding dummy bytes to work around, but still can’t understand why XC8 uses it for code? Am I missing something?
    post edited by Andy123 - 2020/04/02 18:56:03
    #9
    ric
    Super Member
    • Total Posts : 27697
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: EEPROM write time in Q parts 2020/04/02 19:04:00 (permalink)
    +1 (1)
    Yes, as you assume, XC8 should know it can't use that memory when the SAFEN config bit is set, but plainly they have not yet made that automatic.
    If you can be bothered, submitting a support ticket ( http://microcip.com/support ) would be a good way to jog their memory.
     

    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!
    #10
    davea
    Super Member
    • Total Posts : 247
    • Reward points : 0
    • Joined: 2016/01/28 13:12:13
    • Location: Tampa Bay FL USA
    • Status: offline
    Re: EEPROM write time in Q parts 2020/04/02 19:52:37 (permalink)
    0
    just to be sure, your checking
    01FF00h to
    01FFFFh
    #11
    JPortici
    Super Member
    • Total Posts : 1093
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: EEPROM write time in Q parts 2020/04/03 00:23:30 (permalink)
    +1 (1)
    Andy123
    I probably should ask in XC8 forum, but this is related to this thread, so let me try:
    Instead of using EEPROM I am looking to use Storage Area Flash (SAF) that is defined as the last block of flash (128 words).
    Is SAFEN is set, then no code can be executed from that area, But what I see is that compiler puts some code there.
    I can increase my reserved storage size from 152 bytes to 256 adding dummy bytes to work around, but still can’t understand why XC8 uses it for code? Am I missing something?



    Unfortunately the XC8 linker still has no idea that the SAF can exist so you have to work around it, the simplest being declaring an array of the appropriate size at the start of the page containing the SAF
    #12
    Andy123
    Super Member
    • Total Posts : 618
    • Reward points : 0
    • Joined: 2005/04/25 14:20:54
    • Status: offline
    Re: EEPROM write time in Q parts 2020/04/03 09:13:01 (permalink)
    0
    davea
    just to be sure, your checking01FF00h to01FFFFh

    Yes, this is the area.
    Apparently MPLAB IDE is aware of this as it clearly labeled as Storage Area Flash in Program Memory view.
    Not sure where in cofiguration files it’s specifically defined, but MPLAB is aware.
    And I clearly see code in there when looking at disassembly.
    Looks like it’s a linker that puts code there.
    #13
    crosland
    Super Member
    • Total Posts : 1989
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: EEPROM write time in Q parts 2020/04/03 09:24:57 (permalink)
    +3 (3)
    Jack_M
    Unfortunately the XC8 linker still has no idea that the SAF can exist so you have to work around it, the simplest being declaring an array of the appropriate size at the start of the page containing the SAF



    I may be missing something, but why not just exclude it in the linker memory regions?
    #14
    Jump to:
    © 2020 APG vNext Commercial Version 4.5