RD bit stuck on EEPROM read simulating a 18F13K50

Author
bsccara
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2018/06/11 11:07:05
  • Location: 0
  • Status: offline
2018/06/11 18:26:30 (permalink)
0

RD bit stuck on EEPROM read simulating a 18F13K50

I'm attempting to simulate the execution of the following code on a PIC18F13K50 but on the second read the RD bit stays stuck on set and no new data is retrieved, regardless of EEADR changes and additional attempts to set RD.
 
; Prepare to access the EEPROM  <== EECON1 = 0x80 here
BCF EECON1, EEPGD, ACCESS
; Get the offset
MOVWF EEADR
BSF EECON1, RD, ACCESS  <== Here RD never is shown as set and EEPROM data is fetched into EEDATA
MOVFF EEDATA, ep0_ds_ptr_low
; Get the length
INCF EEADR, F, ACCESS
BSF EECON1, RD, ACCESS  <== From here on, RD stays 1 and no new data is fetched
MOVFF EEDATA, ep0_ds_len

 
One possible factor is that the datasheet states that EEADR is mapped at 0xFAA, while both the Microchip-provided include file p18f13k50.inc and the simulator's SFR memory view indicate that it is mapped at 0xFA9, with 0xFAA being unimplemented RAM. (There is an inconsistency between two tables on the current datasheet, one showing 0xFAA and another 0xFA9; according to Microchip the correct address is 0xFA9).
 
post edited by bsccara - 2018/06/13 03:21:23
#1

4 Replies Related Threads

    DeutcheN
    Starting Member
    • Total Posts : 55
    • Reward points : 0
    • Joined: 2010/09/01 12:35:40
    • Location: DM43BH
    • Status: offline
    Re: RD bit stuck on EEPROM read simulating a 18F13K50 2018/06/13 10:37:48 (permalink)
    0
     
      This may be a limitation of the simulator itself.  It does not clear the RD bit after reading from EEPROM.  Manually clearing the bit and setting it again seems to work.
       The RD bit does clear automatically on the actual device.
     
    #2
    GeorgePauley
    Moderator
    • Total Posts : 949
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: RD bit stuck on EEPROM read simulating a 18F13K50 2018/06/13 10:40:55 (permalink)
    0
    Yep it's a simulator bug.  We will fix it in the next release of MPLAB X.  You can work around the bug as follows...
     

    BSF EECON1, RD, ACCESS  <== Here RD never is shown as set and EEPROM data is fetched into EEDATA
    MOVFF EEDATA, ep0_ds_ptr_low
    ; Get the length
    INCF EEADR, F, ACCESS
    BCF EECON1, RD, ACCESS  <== Add this line here
    BSF EECON1, RD, ACCESS  <== From here on, RD stays 1 and no new data is fetched

    #3
    bsccara
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2018/06/11 11:07:05
    • Location: 0
    • Status: offline
    Re: RD bit stuck on EEPROM read simulating a 18F13K50 2018/06/13 18:15:49 (permalink)
    0
    Actually if the code follows the procedure detailed on the DS to the letter, by adding a 'BCF EECON1, EEPGD' just before setting the RD bit, everytime it is set, the simulator works properly.
    I had assumed that if the EEPGD bit was already cleared (globally) there would be no need to do it before every RD, but apparently the simulator requires that access to the EEPGD bit (the CFGS bit can be cleared globally, once) to drive some internal state.
    My currently pending question on Microchip support is whether the silicon also requires the two ops together to successfully read the EEPROM.
    #4
    GeorgePauley
    Moderator
    • Total Posts : 949
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: RD bit stuck on EEPROM read simulating a 18F13K50 2018/06/14 08:54:09 (permalink)
    0
    Hmmm, good question.  The simulator code does indeed clear the RD bit, but it also has a prevRD value that it keeps around to detect edges.  The simulator "forgot" to also clear the prevRD bit, so after the first edge it would never see another edge.  This seemed like an obvious bug, so I just corrected it.  But if it is the case that the silicon actually requires the explicit clear then I should rethink this fix.  (I'm about 95% sure the explicit clear would not be required...)
    #5
    Jump to:
    © 2018 APG vNext Commercial Version 4.5