Hard Fault while accessing external flash memory configured in memory mapped mode

[Mayank1]

Hi,

I have been working on implementing external flash driver integration with TouchGFX on STM32G474-eval board, in memory mapped mode.

I have configured the QSPI in Bank 1 with Single/Dual lines. I have attached an image of my CubeMx configuration.

I am getting hard fault while accessing any memory area of external flash. But, while in debug mode, I am able to access the memory address, for example: 0x90000000.

Below are my QSPI initialisation sequence :

uint8_t CSP_QUADSPI_Init(void) {

if(CSP_QSPI_Erase_Chip() != HAL_OK)

{

return HAL_ERROR;

}

if (QSPI_AutoPollingMemReady(HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {

return HAL_ERROR;

}

if (QSPI_WriteEnable() != HAL_OK) {

return HAL_ERROR;

}

if (QSPI_Configuration() != HAL_OK) {

return HAL_ERROR;

}

if (QSPI_AutoPollingMemReady(HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {

return HAL_ERROR;

}

return HAL_OK;

}

uint8_t CSP_QSPI_EnableMemoryMappedMode(void) {

QSPI_CommandTypeDef sCommand;

QSPI_MemoryMappedTypeDef sMemMappedCfg;

/* Enable Memory-Mapped mode-------------------------------------------------- */

sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE;

sCommand.AddressSize = QSPI_ADDRESS_32_BITS;

sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;

sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;

sCommand.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;

sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

sCommand.AddressMode = QSPI_ADDRESS_1_LINE;

sCommand.DataMode = QSPI_DATA_1_LINE;

sCommand.NbData = 0;

sCommand.Address = 0;

sCommand.Instruction = 0x0BU;

sCommand.DummyCycles = 4;

sMemMappedCfg.TimeOutActivation = QSPI_TIMEOUT_COUNTER_DISABLE;

if (HAL_QSPI_MemoryMapped(&hqspi1, &sCommand, &sMemMappedCfg) != HAL_OK) {

return HAL_ERROR;

}

return HAL_OK;

}

[Romain DIELEMAN]

Hi,

Could you provide some screenshots of the error ? Have you started your project from scratch ?

This is not a TouchGFX related question, could you edit and add the corresponding "Topic" tags (like QSPI and your mcu) ? This will help increasing this post's visibility and getting the right help/knowledgeable people .

/Romain

[Tesla DeLorean]

What make/model of flash part?

Whilst executing code or moving data?

Show a register dump and code at fault.​

[Mayank1]

External flash model is MT25QL512ABB-Micron. I want to configure QSPI in single/Dual mode, not in Quad mode.

[Tesla DeLorean]

Ok, but that's the Hard Fault Handler, not the site of the fault itself.

You need to go unpack what was happening in the getTextureMapperDrawScanLine()

Why do you erase the memory in the initialization code, won't that break things? ie pointers loading as 0xFFFFFFFF ?

The initialization code makes little sense. You shouldn't need to write enable

Look at the STM32G474-EVAL BSP code

[m12lrpv]

I'm not trying to hijack but I am also dealing with unexpected hard faults and i'm extremely new to arm and ST micros so i'm struggling to understand where to start and documentation when googleing doesn't really align with the STM32IDE environment so sorting out what is what can be tricky.

From your reply I'm guessing that the left pane in the screenshot is the stack trace and that the entry prior to the <signal handler called> is "ALLWAYS" the source of the fault. In the screenshot that would be the getTextureMapperDrawScanLine method?

Is this correct?

[Mayank1]

yes

[Mayank1]

I have changed the code :

uint8_t CSP_QUADSPI_Init(void)

{

  /* initialise QSPI */

  HAL_QSPI_DeInit(&hqspi1);

  if (HAL_QSPI_Init(&hqspi1) != HAL_OK)

  {

    return HAL_ERROR;

  }

  if (QSPI_DummyCyclesCfg() != HAL_OK)

  {

    return HAL_ERROR;

  }

  if (QSPI_AutoPollingMemReady() != HAL_OK)

  {

    return HAL_ERROR;

  }

  return HAL_OK;

}

Now, while Debugging or programming using cubeProgrammer. But the data stored in external flash is not readable. Wherever any external flash address is addressed, LCD screen becomes blank. ( I guess filled with 0xFFFFFFFF). In general data is not shown on LCD.

But there is a catch, while reading an external flash address lets say 0x900000000 in a local variable, its getting read successfully.