• AVR Freaks

Hot!Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR)......

Author
Avana
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2017/04/19 02:14:25
  • Location: 0
  • Status: offline
2019/07/06 01:08:09 (permalink)
0

Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR)......

Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR)......
I have been working on PIC18F47K40 since some days, im using xc8 compiler with MPLABX v4.20, my project involves interfacing with EEPROM which is ATML24C08 which is 8kb memory which is used to store some settings of my project. It is required that EEPROM is needed to be read on every microcontroller reset(MCLR) to load the variables with the values stored previously, so data to be read is about 100bytes which is read for every MCLR reset of microcontroller. Problem is when I reset (using a snap switch) my microcontroller very faster (3-4 times in a second), controller stops working and all other functionality will stop (verified it by toggling a port pin in a timer), I have a LCD module along with that which stops and displays nothing and a normal MCLR reset will not get back to its working condition. Power reset (POR) is required to make microcontroller work.
  • Since the EEPROM used is a I2C based device, it is accomplished by using polling method (not using interrupt method) which involves waiting for some while statements (generated using MCC), thought there may be problem with the while statement (missing some acknowledgements may be).
  • Another theory is that whenever microcontroller is reset, controller will reset but there is no option for EEPROM to reset, so I did a small workout connected a 5v supply to EEPROM externally (disconnected from my board) and I tried to get back the problem condition (microcontroller stops working on RESET) in that condition, if I disconnect EEPROM form supply and connect back the microcontroller starts working.
  • In my previous project I was reading very less number of bytes (nearly 15 bytes), presently I’m reading more number of bytes(nearly 100 bytes), I guess controller is taking hell lot of time
  • Below I have mentioned my code part which is generated using MCC (write and read is perfect) to write and read EEPROM.
  • I am reading the EEPROM after the global interrupts and peripheral interrupts are read.
  • I guess watch dog timer should try to reset microcontroller(just using clrwdt(); in while loop start).
 
Questions:
  • How is that I’m going to read the EEPROM without consuming more time?
  • How problem is solved if it is POR but not MCLR?
  • Is there any setting in a microcontroller such that read EEPROM can be avoided for every MCLR reset such that the variables will retain their values after MCLR, but will clear once there is a POR?
  • Can the variables declaration (of any other type) help, to save values in the variables (Which is unsigned int) even after MCLR but should clear everything on POR.
  • Am I in the right path in testing the EEPROM (suggest any if not), is the practice of reading of EEPROM for every MCLR Reset is correct?
  • Why watchdog timer is not helping coming out of that, is there any initialisation for watchdog timer?
void EEP_WriteByte(uint8_t slaveDevAddr, uint8_t eepDataAddr,  uint8_t byte)
{
        uint8_t writeBuffer[2];
        I2C1_MESSAGE_STATUS status = I2C1_MESSAGE_COMPLETE;
        writeBuffer[0] = (uint8_t)(eepDataAddr);
        writeBuffer[1] = byte;
        I2C1_MasterWrite(writeBuffer, 2, slaveDevAddr, &status);
        while(status == I2C1_MESSAGE_PENDING);
        flg_reg2.setclr2.set_chngd = SET;
        Reset_evnt = 1;
        delay(20);
}
uint8_t EEP_ReadByte(uint8_t slaveDevAddr, uint8_t eepDataAddr)
{
        uint8_t writeBuffer[1];
        uint8_t readData;
        I2C1_TRANSACTION_REQUEST_BLOCK readTRB[2];
        I2C1_MESSAGE_STATUS status = I2C1_MESSAGE_COMPLETE;           
        writeBuffer[0] = (uint8_t)(eepDataAddr);             
        I2C1_MasterWriteTRBBuild(&readTRB[0], writeBuffer, 1, slaveDevAddr);             
        I2C1_MasterReadTRBBuild(&readTRB[1], &readData, 1, slaveDevAddr); 
        I2C1_MasterTRBInsert(2, readTRB, &status);
        while(status == I2C1_MESSAGE_PENDING);
        return readData;
        delay(5);
}
 
I’m stuck with this small bug even after completing entire project. Please help me…. Thank u :)..
 
Regards
AVANA
#1

14 Replies Related Threads

    pcbbc
    Super Member
    • Total Posts : 1188
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/06 02:19:32 (permalink)
    +1 (1)
    How is that I’m going to read the EEPROM without consuming more time?

    Don’t know. But likely it isn’t going to fix your problem, just perhaps make it less likely to occur.

    How problem is solved if it is POR but not MCLR?

    Because the POR resets the external EEPROM as well? I don’t know, and you don’t say or provide a circuit diagram.
    But your second bullet point seems to confirm that it is the EEPROM that is locking up, not the MPU - does it not?
    i.e. The MPU only locks up as a result of being unable to communicate with the EEPROM.

    Is there any setting in a microcontroller such that read EEPROM can be avoided for every MCLR reset such that the variables will retain their values after MCLR, but will clear once there is a POR?

    Yes, you can set certain variables so they are not initialised at startup. Then check the cause of the reset and take whatever action you require to initialise them. One of those could be a could be a counter or a flag to say if you were reset while previously still handling the previous reset.

    Can the variables declaration (of any other type) help, to save values in the variables (Which is unsigned int) even after MCLR but should clear everything on POR.

    See section 5.4.8.1 PERSISTENT TYPE QUALIFIER in the XC8 user guide.
    But to “clear” everything on POR you will need to check the cause of the reset I think.

    Am I in the right path in testing the EEPROM (suggest any if not), is the practice of reading of EEPROM for every MCLR Reset is correct?

    In the right path? You don’t present all your code, so we have no idea if you are “in the right path” or not.

    Why watchdog timer is not helping coming out of that, is there any initialisation for watchdog timer?

    Maybe you didn’t configure it correctly, or maybe your code executes the EEPROM action on a WDT reset as well as a MCLR.
    Again, you do not present your full code, so we cannot say.
    #2
    ric
    Super Member
    • Total Posts : 23163
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/06 03:16:04 (permalink)
    +2 (2)
    My guess, your PIC is resetting while the EEPROM is still in the middle of a read cycle, so it is pulling the SDA pin down, which prevents any fresh I2C cycle starting.
    There is a way to get out of this condition, but it involves manually toggling the SDA and SCL pins.
    You need to make SDA an input (so it will float high because of the pullup resistor on SDA), then toggle the SCL pin nine times at 100khz or less. (That is 5us high then 5us low)
    Finish with the SCL pin low. Make SDA an output and pull it low.
    Wait at least 5us, raise SCL, wait at least another 5us, then raise SDA (or make it an input so it floats again).
    This will look like 9 clock cycles followed by a STOP condition, which is guaranteed to get the memory out of a read cycle.
     
     

    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
    Aussie Susan
    Super Member
    • Total Posts : 3607
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/07 19:16:39 (permalink)
    +1 (1)
    You also mention using a switch to reset to the MCU. It could well be that the switch is providing contact bounce and so is resetting your MCU many more times than you think.
    As putting debounce code onto the \MCLR\ pin response is not really sensible, I suggest that you look to hardware debounce circuitry.
    Susan
    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 17596
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/07 19:36:59 (permalink)
    +1 (1)
    With I2C do not wait in a while loop without a timed exit. There are conditions that can cause I2C to get stuck.
    #5
    Avana
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2017/04/19 02:14:25
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 01:10:03 (permalink)
    0
    Thanks ric for your reply...
     
    Memory reset feature helped a lot, but still the microcontroller stops working sometimes but im able to come out by pressing another reset.... i would like to show u my code...
    this is the part of my code i'm using to toggle SCL line 9 times, but i have placed this function before the system initialization(in which pin management and I2C are initialized), if the function is placed after the system initialization microcontroller stops working again.
     
    Also while setting TRIS bits both SCL and SDA are considered to be inputs, if i try to make it outputs again microcontroller stops. still i'm stuck.....
     
          SDA1_PORT = 1;
          SDA1_PORT = 0;
          SCL1_PORT = 0;
          SDA1_PORT = 1;
          for(i=0;i<10;i++)
          {
            SCL1_PORT = 1;
            delay(10);
            SCL1_PORT = 0;
            delay(10);
          }
          SCL1_PORT = 1;
          SDA1_PORT = 1;  
     
    is the above code part to reset eeprom correct?
    #6
    Avana
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2017/04/19 02:14:25
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 01:13:27 (permalink)
    0
    Thanks for your reply...
     
    I have used a snap switch and a capacitor of 100nf for hardware debounce i hope it is sufficient.... correct me if im wrong (capacitor value to be increased to uF or something lyk that)....
    #7
    Avana
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2017/04/19 02:14:25
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 01:22:34 (permalink)
    0
    pcbbc
    How is that I’m going to read the EEPROM without consuming more time?

    Don’t know. But likely it isn’t going to fix your problem, just perhaps make it less likely to occur.

    How problem is solved if it is POR but not MCLR?

    Because the POR resets the external EEPROM as well? I don’t know, and you don’t say or provide a circuit diagram.
    But your second bullet point seems to confirm that it is the EEPROM that is locking up, not the MPU - does it not?
    i.e. The MPU only locks up as a result of being unable to communicate with the EEPROM.

    Is there any setting in a microcontroller such that read EEPROM can be avoided for every MCLR reset such that the variables will retain their values after MCLR, but will clear once there is a POR?

    Yes, you can set certain variables so they are not initialised at startup. Then check the cause of the reset and take whatever action you require to initialise them. One of those could be a could be a counter or a flag to say if you were reset while previously still handling the previous reset.

    Can the variables declaration (of any other type) help, to save values in the variables (Which is unsigned int) even after MCLR but should clear everything on POR.

    See section 5.4.8.1 PERSISTENT TYPE QUALIFIER in the XC8 user guide.
    But to “clear” everything on POR you will need to check the cause of the reset I think.

    Am I in the right path in testing the EEPROM (suggest any if not), is the practice of reading of EEPROM for every MCLR Reset is correct?

    In the right path? You don’t present all your code, so we have no idea if you are “in the right path” or not.

    Why watchdog timer is not helping coming out of that, is there any initialisation for watchdog timer?

    Maybe you didn’t configure it correctly, or maybe your code executes the EEPROM action on a WDT reset as well as a MCLR.
    Again, you do not present your full code, so we cannot say.

    Thanks for your reply...
    Below is the code for pragma part which says WDT is initialised. i guess it is correct correct me if im wrong.
    // CONFIG1L
    #pragma config FEXTOSC = OFF    // External Oscillator mode Selection bits->Oscillator not enabled
    #pragma config RSTOSC = HFINTOSC_64MHZ    // Power-up default value for COSC bits->HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1

    // CONFIG1H
    #pragma config CLKOUTEN = OFF    // Clock Out Enable bit->CLKOUT function is disabled
    #pragma config CSWEN = ON    // Clock Switch Enable bit->Writing to NOSC and NDIV is allowed
    #pragma config FCMEN = ON    // Fail-Safe Clock Monitor Enable bit->Fail-Safe Clock Monitor enabled

    // CONFIG2L
    #pragma config MCLRE = EXTMCLR    // Master Clear Enable bit->If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR
    #pragma config PWRTE = OFF    // Power-up Timer Enable bit->Power up timer disabled
    #pragma config LPBOREN = OFF    // Low-power BOR enable bit->ULPBOR disabled
    #pragma config BOREN = SBORDIS    // Brown-out Reset Enable bits->Brown-out Reset enabled , SBOREN bit is ignored

    // CONFIG2H
    #pragma config BORV = VBOR_2P45    // Brown Out Reset Voltage selection bits->Brown-out Reset Voltage (VBOR) set to 2.45V
    #pragma config ZCD = OFF    // ZCD Disable bit->ZCD disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON
    #pragma config PPS1WAY = ON    // PPSLOCK bit One-Way Set Enable bit->PPSLOCK bit can be cleared and set only once; PPS registers remain locked after one clear/set cycle
    #pragma config STVREN = ON    // Stack Full/Underflow Reset Enable bit->Stack full/underflow will cause Reset
    #pragma config DEBUG = OFF    // Debugger Enable bit->Background debugger disabled
    #pragma config XINST = OFF    // Extended Instruction Set Enable bit->Extended Instruction Set and Indexed Addressing Mode disabled

    // CONFIG3L
    #pragma config WDTCPS = WDTCPS_31    // WDT Period Select bits->Divider ratio 1:65536; software control of WDTPS
    #pragma config WDTE = ON    // WDT operating mode->WDT enabled regardless of sleep

    // CONFIG3H
    #pragma config WDTCWS = WDTCWS_7    // WDT Window Select bits->window always open (100%); software control; keyed access not required
    #pragma config WDTCCS = SC    // WDT input clock selector->Software Control

    // CONFIG4L
    #pragma config WRT0 = OFF    // Write Protection Block 0->Block 0 (000800-003FFFh) not write-protected
    #pragma config WRT1 = OFF    // Write Protection Block 1->Block 1 (004000-007FFFh) not write-protected
    #pragma config WRT2 = OFF    // Write Protection Block 2->Block 2 (008000-00BFFFh) not write-protected
    #pragma config WRT3 = OFF    // Write Protection Block 3->Block 3 (00C000-00FFFFh) not write-protected
    #pragma config WRT4 = OFF    // Write Protection Block 3->Block 4 (010000-013FFFh) not write-protected
    #pragma config WRT5 = OFF    // Write Protection Block 3->Block 5 (014000-017FFFh) not write-protected
    #pragma config WRT6 = OFF    // Write Protection Block 3->Block 6 (018000-01BFFFh) not write-protected
    #pragma config WRT7 = OFF    // Write Protection Block 3->Block 7 (01C000-01FFFFh) not write-protected

    // CONFIG4H
    #pragma config WRTC = OFF    // Configuration Register Write Protection bit->Configuration registers (300000-30000Bh) not write-protected
    #pragma config WRTB = OFF    // Boot Block Write Protection bit->Boot Block (000000-0007FFh) not write-protected
    #pragma config WRTD = OFF    // Data EEPROM Write Protection bit->Data EEPROM not write-protected
    #pragma config SCANE = ON    // Scanner Enable bit->Scanner module is available for use, SCANMD bit can control the module
    #pragma config LVP = ON    // Low Voltage Programming Enable bit->Low voltage programming enabled. MCLR/VPP pin function is MCLR. MCLRE configuration bit is ignored

    // CONFIG5L
    #pragma config CP = OFF    // UserNVM Program Memory Code Protection bit->UserNVM code protection disabled
    #pragma config CPD = OFF    // DataNVM Memory Code Protection bit->DataNVM code protection disabled

    // CONFIG6L
    #pragma config EBTR0 = OFF    // Table Read Protection Block 0->Block 0 (000800-003FFFh) not protected from table reads executed in other blocks
    #pragma config EBTR1 = OFF    // Table Read Protection Block 1->Block 1 (004000-007FFFh) not protected from table reads executed in other blocks
    #pragma config EBTR2 = OFF    // Table Read Protection Block 2->Block 2 (008000-00BFFFh) not protected from table reads executed in other blocks
    #pragma config EBTR3 = OFF    // Table Read Protection Block 3->Block 3 (00C000-00FFFFh) not protected from table reads executed in other blocks
    #pragma config EBTR4 = OFF    // Table Read Protection Block 4->Block 4 (010000-013FFFh) not protected from table reads executed in other blocks
    #pragma config EBTR5 = OFF    // Table Read Protection Block 5->Block 5 (014000-017FFFh) not protected from table reads executed in other blocks
    #pragma config EBTR6 = OFF    // Table Read Protection Block 6->Block 6 (018000-01BFFFh) not protected from table reads executed in other blocks
    #pragma config EBTR7 = OFF    // Table Read Protection Block 7->Block 7 (01C000-01FFFFh) not protected from table reads executed in other blocks

    // CONFIG6H
    #pragma config EBTRB = OFF    // Boot Block Table Read Protection bit->Boot Block (000000-0007FFh) not protected from table reads executed in other blocks


     
    And does uc has the feature that EEPROM read can be blocked on WDT reset...?
    Also Persistant type declaration helps in this context i guess but im trying with EEPROM memory reset just to simplify.
    #8
    pcbbc
    Super Member
    • Total Posts : 1188
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 02:00:40 (permalink)
    +1 (1)
    avanaelectrosystemsAnd does uc has the feature that EEPROM read can be blocked on WDT reset...?

    No.  If you want to take specific action on a WDT reset, you need to test for the reset reason and adjust your program logic accordingly.
     
    See section 8.11 Determining the Cause of a Reset and check the STATUS and PCON0 register before your initialisation.
    #9
    ric
    Super Member
    • Total Posts : 23163
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 02:15:13 (permalink)
    +1 (1)
    What are the first four instructions meant to be doing?
    avanaelectrosystems
          SDA1_PORT = 1;
         SDA1_PORT = 0;
         SCL1_PORT = 0;
         SDA1_PORT = 1;

    Where do you set SDA as an input?
     
    There is no delay between the above instruction setting SCL1 low, and the first instruction settings SCL1 high.
    You must NOT create clocks faster than 100kHz when doing this.
    How long is "delay(10)" in microseconds?
     

    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
    Avana
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2017/04/19 02:14:25
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 04:04:06 (permalink)
    0
    ric
    What are the first four instructions meant to be doing?
    avanaelectrosystems
          SDA1_PORT = 1;
        SDA1_PORT = 0;
        SCL1_PORT = 0;
        SDA1_PORT = 1;

    Where do you set SDA as an input?
     
    There is no delay between the above instruction setting SCL1 low, and the first instruction settings SCL1 high.
    You must NOT create clocks faster than 100kHz when doing this.
    How long is "delay(10)" in microseconds?
     
    ric
    What are the first four instructions meant to be doing?
    avanaelectrosystems
          SDA1_PORT = 1;
        SDA1_PORT = 0;
        SCL1_PORT = 0;
        SDA1_PORT = 1;

    Where do you set SDA as an input?
     
    There is no delay between the above instruction setting SCL1 low, and the first instruction settings SCL1 high.
    You must NOT create clocks faster than 100kHz when doing this.
    How long is "delay(10)" in microseconds?
     


    This is the delay code I'm working with
     void delay(int dly)  
    {
          int i;
        dly = dly*250;                        //100    //changed on 8/10/12 for 64Mhz    //for 32MHz crystal
          for(i = 0;i <= dly;i++)
        Nop();
    }
     
    Here 1 NOP = 4 machine cycles
    system freq = 64Mhz
    so 64M/4 = 16Mhz
    so for 1 NOP = 1/16M = 62.5ns
    I have 250 NOP and calling the delay of 20
    so 62.5n*250*20 = 312us
    delay(20) = 312us
     
    I guess it is right..... and it is well above than 100Khz
     
    Now i have remove the first four lines retaining only for loop and increasing the delay(10) to delay(20)
     
          for(i=0;i<10;i++)
          {
            SCL1_PORT = 1;
            delay(20);
            SCL1_PORT = 0;
            delay(20);
          }
     
    And initialization seems ok and i have the problem of microcontroller stopping after pressing microcontroller sometimes.
    Do u have any suggestions to still refine my code....??
    Do u think we need to modify SDA....??
     
    post edited by Avana - 2019/07/09 04:10:29
    #11
    ric
    Super Member
    • Total Posts : 23163
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 04:12:28 (permalink)
    +1 (1)
    Why didn't you just use the __delay_us() macro provided by the compiler?
    That is guaranteed to work regardless of any optimisation the compiler might do.
     
    You still don't mention where you set SDA as an input. I can't point out problems if you don't show all the relevant code.
    You did NOT do any of the things I mentioned AFTER sending the nine clock pulses.
     

    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
    Aussie Susan
    Super Member
    • Total Posts : 3607
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 19:51:06 (permalink)
    +1 (1)
    In your config entries you have 2 items that concern me.
    1) DEBUG - never - just *NEVER* - set this item to anything. Let the IDE do that for you.
    2) PPS1WAY - you have this set to be ON which means that once you lock the PPS registers, they cannot be unlocked until (according to the data sheet) a 'device reset'.
    I've not used that device but it is possible that whatever is making your device restart may not be considered a 'reset' in which case the PPS registers will remain locked, even if you try to unlock them as part of your initialisation code.
    I would set this config item to OFF so that the PPS registers can be unlocked as often as you like - at least it wil remove one source of possible error for you.
    Susan
    #13
    Avana
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2017/04/19 02:14:25
    • Location: 0
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/09 22:34:43 (permalink)
    0
    ric
    Why didn't you just use the __delay_us() macro provided by the compiler?
    That is guaranteed to work regardless of any optimisation the compiler might do.
     
    You still don't mention where you set SDA as an input. I can't point out problems if you don't show all the relevant code.
    You did NOT do any of the things I mentioned AFTER sending the nine clock pulses.
     


    void main(void)
    {

        SDA_conf();
        SYSTEM_Initialize();
        NVMCON1bits.NVMREG = 2;
        psw_digit = PSW_EDIT0;
        SetReg = 0;
        EditReg = 0;
        lcd_init();    
        ADC_Init();
    //----------------------- Imp initialisations --------------------------------//
        led_reg.ledstatus = 0x00;                    
        led_update();
     //---------------------------------------------------------------------------//
           DisplayCnt = 0;
        grp_selec = 0;
        /* if communication is selected as 103, Device address & Baudrate is fixed*/
        if(flg_reg51.setclr51.MBUS_103 == IEC103)       
        {
            dva_reg = 247;
            Bd_rate = 9600;
        }
        else if(flg_reg51.setclr51.MBUS_103 == MODBUS)
        {
            dva_reg = dva_comm;
            Bd_rate = Bd_comm;
        }
        USART_init();
        USART2_init();    
        setg_calc();
        flg_reg2.setclr2.set_chngd = CLEAR;
         Reset_evnt = CLEAR;
        mTC_value = TC_value;            
    //-------------mcc generated code---------------------------------------------//
        INTERRUPT_GlobalInterruptHighEnable();
        INTERRUPT_PeripheralInterruptEnable();
        INTERRUPT_GlobalInterruptLowEnable();
    //----------------------------------------------------------------------------//
        RTC_init();        //this fun should be called after relay inititialisation      //this is called after global interrupt becz  RTC write trough i2c interrupt
        flg_reg2.setclr2.set_chngd = CLEAR;
        Reset_evnt = CLEAR;
        clr_scrn();
    //    EEP_WriteByte(slaveDeviceAddress, dfault_add1, 0xff);            
    //    EEP_WriteByte(slaveDeviceAddress, dfault_add2, 0xff);
    //    SDA_conf();
        read_ver_setng();                                                            //this is called after global interrupt becz  e2prom write trough i2c interrupt
        WDefault();
        read_E2prom();                                                                //this is called after global interrupt becz  e2prom write trough i2c interrupt
        setg_calc();
        flg_reg2.setclr2.set_chngd = CLEAR;
         Reset_evnt = CLEAR;
        mTC_value = TC_value;   
     
    ......//continued
    }
    void SDA_conf(void)
    {
          unsigned char i;
          for(i=0;i<10;i++)
          {
            SCL1_PORT = 1;
            __delay_us(1000);
            SCL1_PORT = 0;
            __delay_us(1000);
          }      
          SCL1_PORT = 0;
          TRISCbits.TRISC4 = 0;//SDA tris output
          SDA1_PORT = 0;
          __delay_us(1000);
          SCL1_PORT = 1;
          __delay_us(1000);
          SDA1_PORT = 1;    
          TRISCbits.TRISC4 = 1;//SDA tris input
    }
    void SYSTEM_Initialize(void)
    {
        INTERRUPT_Initialize();
        PMD_Initialize();
        PIN_MANAGER_Initialize();
        OSCILLATOR_Initialize();
        I2C1_Initialize();
       // ADC_Init();
       // TMR1_Initialize();
    }
    The above shows the code part.....
    SDA is set as in put in pin manager in system initialization....
    i have even done the things which u have  mentioned after nine clock pulses.....
    delay of 1000 is ok i guesss....???
    still the problem of microcontroller stopping exists, but on MCLR reset it can wake up again(which was not happening before with my code)....
    #14
    Aussie Susan
    Super Member
    • Total Posts : 3607
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Continous MCLR reset will make microcontroller to stop (if EEPROM is read on MCLR).... 2019/07/10 20:49:32 (permalink)
    0
    If the first thing that is called is 'SDA_conf', then the TRISx registers will be at their default which is '1' (INPUT).
    Perhaps moving the call to 'SDA_conf' to after where the MCC has initialised the whole device might help.
    Susan
    #15
    Jump to:
    © 2019 APG vNext Commercial Version 4.5