How to debug this I2C hard fault?

Question

I am using an STM32F103C8T6, STM32CubeIDE with HAL.

During accessing an LCD (1602), with I2C, I get a hard fault.

I try to debug it, but somehow I don't see the stack. See the following screenshot:

The breakpoint happens inside the stm32f1xx_hal_i2c, in this code (==> is break point):

static HAL_StatusTypeDef I2C_WaitOnFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t Flag, FlagStatus Status, uint32_t Timeout, uint32_t Tickstart)
{
  /* Wait until flag is set */
  ==> while (__HAL_I2C_GET_FLAG(hi2c, Flag) == Status)
  {
    /* Check for the Timeout */
    if (Timeout != HAL_MAX_DELAY)
    {
      if (((HAL_GetTick() - Tickstart) > Timeout) || (Timeout == 0U))
      {
        hi2c->PreviousState     = I2C_STATE_NONE;
        hi2c->State             = HAL_I2C_STATE_READY;
        hi2c->Mode              = HAL_I2C_MODE_NONE;
        hi2c->ErrorCode         |= HAL_I2C_ERROR_TIMEOUT;

        /* Process Unlocked */
        __HAL_UNLOCK(hi2c);

        ==> return HAL_ERROR;
      }
    }
  }
  return HAL_OK;
}

This function is called from within many functions inside the same file.

The hard fault occurs after return HAL_ERROR in the same function, than the next function in the 'while' loop, and when I jump INTO the while (so calling __HAL_I2C_GET_FLAG). During the call to that last function, the following stack is shown:

How can I debug what's happening exactly in between the call and the hard fault? Or even better, does anybody have a reason how such hard fault can happen in an STM library inside HAL?

Answer 1

For future reference, you need to define DEBUG_DEFAULT_INTERRUPT_HANDLERS in your preprocessor macros to capture the real cause of the hardfault interrupt.

Unfortunately, I don't know how to do this with the STM32CubeIDE. Here is a tutorial on how to do it with VisualGDB and hopefully this points you in the right direction: https://visualgdb.com/tutorials/arm/tracing/traceback/

Answer 2

Note that the solution was in a completely different part than the question mentions.

The problem was, that I use EEPROM simulation, which means on an STM32 that part of the flash is overwritten.

By default page 15 is used (out of 31) which means like about less than half way of the 64 KB Flash it has.

Since my program is growing gradually, instead of formatting/writing to the 'EEPROM simulation' Flash space, it was overwriting my program.

I changed the page number to 30 and now the problem is solved (unless my program gets too big again).

I thought the simulation flash 'library' would use the next 'free' page but it does not.

Answer 3

Your debugging strategy should be to set a breakpoint as close to the fault as possible, and step one line at a time until you find the exact location of the fault. Make sure your compiler optimization settings are 'optimized for debug' or off or it might skip lines/execute them in a different order.

I think you're looking at the wrong piece of code. Hard faults are usually due to bad memory access. You're clearly using one of the blocking HAL I2C functions, so if I had to guess I'd say you're probably overrunning an array. Check your array size and make sure you're calling your I2C function with the correct number of bytes.