HardFault Handler while implementing I2C OLED.

[Raahul Jagannathan]

Posted on June 18, 2018 at 09:59

I am implementing a 3 channel frequency counter. So I get 3 different frequency values as inputs. I am using SSD1306 driver to interface the I2C-OLED. When I try to print only one of the frequencies, it works fine. However on trying to print more than 1, I am getting a hardfault error, and it gets stuck in the while loop. What is the cause of this error?

[AvaTar]

Posted on June 18, 2018 at 11:13

Hardfault usually means a 'hard' bug in your code.

However on trying to print more than 1, ...

If you mean printf(), the problem might be stack size. Some clib functions use lots of stack.

Try increasing it in your project settings.

[Raahul Jagannathan]

Posted on June 18, 2018 at 12:57

It isnt printf(). This is when I am trying to display it on the OLED display. The body of my code is:

count=SSD1306_Init();

char dem[1000]; //char dem1[1000]; //char dem2[1000]; sprintf(dem,'%u',uwFrequency); //sprintf(dem1,'%u',uwFrequency1); //sprintf(dem2,'%u',uwFrequency2); SSD1306_Fill(0); //Fills colour as black SSD1306_UpdateScreen(); //Prints the changes SSD1306_GotoXY(1,1); //Goes to the point 10,10 SSD1306_Puts('Multi Channel', &Font_7x10, 1); SSD1306_GotoXY(1,10); //Goes to the point 10,10 SSD1306_Puts('Frequency Counter:', &Font_7x10, 1); SSD1306_GotoXY(1,22); SSD1306_Puts('Freq 1:', &Font_7x10, 1); SSD1306_GotoXY(50,22); SSD1306_Puts(dem, &Font_7x10, 1); SSD1306_GotoXY(1,37); SSD1306_Puts('Freq 2:', &Font_7x10, 1); //SSD1306_GotoXY(50,37); //SSD1306_Puts(dem1, &Font_7x10, 1); SSD1306_GotoXY(1,52); SSD1306_Puts('Freq 3:', &Font_7x10, 1); //SSD1306_GotoXY(50,52); //SSD1306_Puts(dem2, &Font_7x10, 1); SSD1306_UpdateScreen(); //for(int dell=0;dell<100000;dell++); //HAL_Delay(300);

On leaving the lines that are in bold, in comments, the program runs fine. It is on including these lines that I encounter a hardfault.

[AvaTar]

Posted on June 18, 2018 at 13:19

It isnt printf().

Whatever it is.

I suggest to step into the offending function(s), identify the code (line) where the hardfault occurs, and check the circumstance. Like checking the address of the object accessed at this line. Understanding assembly code comes in handy here.

[Tesla DeLorean]

Posted on June 18, 2018 at 13:40

Does somewhat lean toward having an inadequate stack, or linking the wrong libraries.

Around here I make sure I have a USART or SWV connection to get debugging information, and have a Hard Fault Handler that outputs internal registers so the exact line of code can be identified. Most hard Faults are a result of touching memory inappropriately. You need to drill down to the assembly code, and look at the processor registers at the fault to see what was going on.