0
\$\begingroup\$

My goal is to communicate with SSD1306 controller of OLED 128x32 display with PIC16F15323 which has I2C interface built-in. Obviously, I've read whole documentation for my MCU and for SSD1306 controller and have followed what's needed. But for some reason my PIC has started to initiate resets after each "__delay_ms()" function. I will leave link to GitHub repository here for you to read what I've wrote.

My main question is - why does MCU reset?

GitHub repository: https://github.com/VestnikAUE/OLED-Display-I2C-PIC16F15323.git

P.S. In the code you will find additional information.

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

Unless you know exactly what you're doing, and for some insane reason you need very exotic behavior (which you don't), you should never return the main function on an embedded controller.

In other words: don't ever return the main function in embedded C.

Add a while (1) {} on the line before return;. That's usually the place where your application runs from the main context (as opposed to the interrupt context).

void main(void)
{
    // low level / peripheral inits
    
    // application inits
    
    beginTransmission(ADDR);
    
    sendControlByte(0x40);
    
    for (unsigned char i = 0; i < 8; i++)
        sendCommand(0x01);
    
    endTransmission();
    
    // !!! add missing while-forever loop !!!
    while (1)
    {
        // application code
    }

    return;
}

Your code executes and then returns from main, which can cause behavior you don't expect.

Relevant question: Who receives the value returned by main()?


I'm adding the relevant part of the original code for reference, since the external source can change or be removed at any time:

#include "CONFIG.h"

// I have to mention that I run MCU from 5V pins from Arduino Uno. Pins SDA and SCL of display are pulled-up.
void main(void)
{
    // I have two LEDs on pins RC3 and RC4 to check if MCU works.
    TRISC = 0b000000;
    PORTC = 0b011000;
    __delay_ms(1000);
    PORTC = 0b000000;
    
    // Searching through Internet I found some causes to resets - PO and TO bits.
    // Here I am checking them. Also they are negated, so LEDs must light up.
    if (__timeout && __powerdown) PORTC = 0b011000;
    else if (__timeout && !__powerdown) PORTC = 0b010000;
    else if (!__timeout && __powerdown) PORTC = 0b001000;
    __delay_ms(2000);
    // I suppose PIC resets here 'cause LEDs blink with those periods.
    PORTC = 0b000000;
    
    i2cBegin();
    
    setupI2C();
    
    beginTransmission(ADDR);
    
    sendControlByte(0x00);
    
    sendCommand(0x26);
    sendCommand(0x00);
    sendCommand(0x05);
    sendCommand(0x00);
    sendCommand(0x07);
    sendCommand(0x2F);
    
    endTransmission();
    
    beginTransmission(ADDR);
    
    sendControlByte(0x40);
    
    for (unsigned char i = 0; i < 8; i++)
        sendCommand(0x01);
    
    endTransmission();
    
    // Test: blinking LEDs program
    /*
    
    TRISCbits.TRISC0 = 0;
    TRISCbits.TRISC1 = 0;
    while (1)
    {
        PORTC = 0b000001;
        __delay_ms(2000);
        PORTC = 0b000010;
        __delay_ms(2000);
    }
    */
    return;
}
\$\endgroup\$
2
  • \$\begingroup\$ Thank you so much! My PIC finally stopped resetting! \$\endgroup\$ Feb 27, 2023 at 14:52
  • \$\begingroup\$ Interesting to know how this PIC controller behaves. The TI controllers I've used in the past will end up in an endless loop. Not that it's really relevant, b/c this behavior shouldn't be triggered anyways. \$\endgroup\$
    – Velvet
    Feb 27, 2023 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.