• AVR Freaks

dsPIC33F - EEPROM Emulation Concerns

Author
Post
Essentials Only Full Version
Adam.Lewis
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2013/08/08 06:45:37
  • Location: 0
  • Status: offline
2013/08/08 07:00:39 (permalink)
0

dsPIC33F - EEPROM Emulation Concerns

I now have two applications, in the development stage, that use the EEPROM Emulation library provided by Microchip (very clever way of wear leveling).  My concern is that the applications running on the dsPIC33FJ128GP706 (non-A) can be damaged using this library after discovering the errata that the device ID can be corrupt / erased when programing memory using the WordWrite.  After digging into DEE Emulation 16-bit.c I confirmed my fear found in the DataEEWrite() function sets NVMCON to ProgramWord.
 
I hope I am missing something here, otherwise there could be a substantial number of users effected by this because this product family also was limited to flash erase/write cycles of min 100.  Based on a number of threads, the #1 recommended thing to do on these chips is to use the EEPROM emulation for the wear leveling (followed closely by use a different family).  
 
Can someone help clear the water here?
 
-- Adam Lewis
 
PS: The BOM has been changed to the "A" part for actual production parts, but the question stills stands.  
#1

4 Replies Related Threads
    Neiwiertz
    Super Member
    • Total Posts : 2094
    • Reward points : 0
    • Joined: 2004/09/01 02:58:52
    • Status: offline
    Re:dsPIC33F - EEPROM Emulation Concerns 2013/08/09 01:33:02 (permalink)
    5 (1)
    Good catch, i readed the errata DS80446F-page 16, and at DS70286C-page 73 NVMOP is set to word by the line(s) NVMCON = PROGRAM_ROW used by the DEE as you explained,
    From the errata i understand device id can be gone and peripherals can be reconfigured at the occurence as soon device id get lost, if your uC was running at this time for that particular occurence and peripheral gets reconfigured which is used by  uC user application would be nasty. (maybe possible to set write protect at device id through by configuration bits) Any other tools than ICD2, RealICE and PM3 Tools as noted at the errata which use word programming can trigger this, it also state that it occurs immediately after RTSP or ICSP therefore if user application waits for a few ??? ms before configure the periheral would be save, my question would be will this errata triggered each word write even if the device id already is gone? than wait for a few ??? ms wouldn't be a workarround for user application perspective, a missing device id can be un needed if never get used any more
     
    Don't know if word vs row programming will cost more endurance of flash for the DEE point of view, maybe DEE can be enhanced to try to read device id and if particular device id is found use row programming instead if possible but if the behaviour only can occur once i would try to live it and use a wait for a few ??? ms
     
    I would ask microchip if this event can occur only once or multiple times
     

    Flying With --|Explorer 16|HardWare|SoftWare|-- Fav(s) Gallery Lists
    #2
    Adam.Lewis
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2013/08/08 06:45:37
    • Location: 0
    • Status: offline
    Re:dsPIC33F - EEPROM Emulation Concerns 2013/08/09 06:44:12 (permalink)
    0
    I had the same thought on changing the emulation to row programing vs word programming.  However based on other micros the endurance is measured by erase/write cycles.   During row programming the earlier portions of the rows will be written far more frequently than the end of the rows.
     
    Thanks for helping confirm my fears.  Luckily I have a production workaround for the time being.
    #3
    philsax
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2013/10/25 00:19:38
    • Location: 0
    • Status: offline
    Re:dsPIC33F - EEPROM Emulation Concerns 2014/01/14 08:36:24 (permalink)
    0
    Good morning, I'd like to move the 'predefined' DEE emulation  area, which in my project the linker gives the following address (and name : _0300CC0052d53574    ) : 
     
    Program Memory  [Origin = 0x200, Length = 0x2adea]
    section                    address   length (PC units)   length (bytes) (dec)
    -------                    -------   -----------------   --------------------
    .text                        0x200              0x1408          0x1e0c  (7692)
    .text                       0x1608               0x1c4           0x2a6  (678)
    .text                       0x17cc                0x32            0x4b  (75)
    _0300CC0052d53574           0x1800              0x4000          0x6000  (24576)
    .const                      0x5800              0x23f6          0x35f1  (13809)
    .text                       0x7bf6              0x24b2          0x370b  (14091)
    .dinit                      0xa0a8               0x36c           0x522  (1314)
    .text                       0xa414               0x252           0x37b  (891)
    .text                       0xa666               0x496           0x6e1  (1761)
    .text                       0xaafc                 0xc            0x12  (18)
     
    I  wish to move the DEE section above to the end of program memory area, fairly beyond the program memory end address,  also to allow and make sure to preserve the NVRAM data  when updating the program in flash, thru bootloader  .   Has anyone  already arranged the DEE program memory to satisfy this requisites ,  or could anyone give me some useful tips about this?
    thanks
     
    #4
    Adam.Lewis
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2013/08/08 06:45:37
    • Location: 0
    • Status: offline
    Re:dsPIC33F - EEPROM Emulation Concerns 2014/01/16 20:10:44 (permalink)
    0
    I ended up putting the app data ahead of the program space.  This allows you to change to smaller / larger parts without having to drastically change your linker script(s).  This best source I have found so far when bringing up the dsPIC33F was a post here on the Microchip forums.  It can be found here (
     
    Application Memory Layout
    /
     MEMORY
     {
       data  (a!xr)   : ORIGIN = 0x800,         LENGTH = 0x4000
       app_data       : ORIGIN = 0x3000,        LENGTH = 0x800 /* 4 pages of app storage */
       reset          : ORIGIN = 0x3800,        LENGTH = 0x4
       ivt            : ORIGIN = 0x3804,        LENGTH = 0x1F8
       program (xr)   : ORIGIN = 0x3A00,        LENGTH = 0x11C00
       bootstatus     : ORIGIN = 0x15600,       LENGTH = 0x200
     }

     
    Bootloader Memory Layout

     MEMORY
     {
       data  (a!xr)   : ORIGIN = 0x800,         LENGTH = 0x4000
       reset          : ORIGIN = 0x0,           LENGTH = 0x4
       ivt            : ORIGIN = 0x4,           LENGTH = 0xFC
       _reserved      : ORIGIN = 0x100,         LENGTH = 0x4
       aivt           : ORIGIN = 0x104,         LENGTH = 0xFC
       program (xr)   : ORIGIN = 0x200,         LENGTH = 0x2E00
       FBS            : ORIGIN = 0xF80000,      LENGTH = 0x2
       FSS            : ORIGIN = 0xF80002,      LENGTH = 0x2
       FGS            : ORIGIN = 0xF80004,      LENGTH = 0x2
       FOSCSEL        : ORIGIN = 0xF80006,      LENGTH = 0x2
       FOSC           : ORIGIN = 0xF80008,      LENGTH = 0x2
       FWDT           : ORIGIN = 0xF8000A,      LENGTH = 0x2
       FPOR           : ORIGIN = 0xF8000C,      LENGTH = 0x2
       FICD           : ORIGIN = 0xF8000E,      LENGTH = 0x2
       FUID0          : ORIGIN = 0xF80010,      LENGTH = 0x2
       FUID1          : ORIGIN = 0xF80012,      LENGTH = 0x2
       FUID2          : ORIGIN = 0xF80014,      LENGTH = 0x2
       FUID3          : ORIGIN = 0xF80016,      LENGTH = 0x2
     }
      


    #5
    Jump to:
    © 2020 APG vNext Commercial Version 4.5