search

STMicroelectronics / STM32CubeH7

STM32Cube MCU Full Package for the STM32H7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
https://www.st.com/en/embedded-software/stm32cubeh7.html
Other
530 stars 312 forks source link

Bank mapping support is broken #150

Closed AAganichev closed 3 years ago

AAganichev commented 3 years ago

Describe the set-up We use custom board with the external Flash connected to NOR/PSRAM Bank 1

Describe the bug There's two issues with the bank mapping support in SDK 1.9.0:

  1. NOR_MEMORY_ADDRESS{1-4} are hardcoded in the stm32h7xx_hal_nor.h and not changed with the setting of bank mapping in CubeMX.
  2. SDK 1.9.0 introduces access to the flash at the end of HAL_NOR_Init() which cause HardFault because of HAL_SetFMCMemorySwappingConfig() called after initializing of first bank.

How To Reproduce

  1. Set bank mapping in CubeMX to "NOR/PSRAM bank and SDRAM bank1/bank2 are swapped".
  2. Setup "NOR Flash/PSRAM/SRAM/ROM/LCD 1" as NOR Flash
  3. Correct NOR_MEMORY_ADDRESS1 to point to 0xc0000000 in stm32h7xx_hal_nor.h
  4. Write a test code to read data from 0xc0000000.
  5. Run and get a HardFault inside HAL_NOR_Init().

Additional context I propose make definitions of NOR_MEMORY_ADDRESS{1-4} dependent on swapping config.

RKOUSTM commented 3 years ago

Hi @AAganichev,

Thank you for your contribution.

In order to allow a better analysis of this problem, could you please give us more details about the application that you are using to reproduce this issue or did you use one of our applications? Otherwise, it is possible to share with us a code snippet allowing our development teams to reproduce it.

Also, could you please confirm you are using the latest firmware version and that the issue is systematically reproducible on your side?

Thank you again for your contribution.

With regards,

AAganichev commented 3 years ago

You don't need even specific application. You need a board with NOR Flash (though SRAM will also work for testing purpose) on CS1, configure CS as NOR Flash (even if it contains SRAM) and setup bank mapping. Then you have two options: 1) Add a single line to the generated from CubeMX application after memory init: volatile int i = (volatile int )NOR_MEMORY_ADDRESS1; Run app and get HardFault because of NOR_MEMORY_ADDRESS1 points to 0x60000000 instead of 0xc0000000. 2) Correct NOR_MEMORY_ADDRESS1 to point to 0xc0000000 in stm32h7xx_hal_nor.h as it should. Run application and you'll get HardFault because of access to memory before remapping.

RKOUSTM commented 3 years ago

Hi @AAganichev,

Thank you for your reports. This point is related to the CubeMX generation problem and not directly related to the firmware published in this repository. We tried once more to reproduce the issue you have described using one of our examples on STM32H743I_EVAL board published in this repository, with no success. You can refer to the BSP example to develop your application. This example shows how to erase, write and read the NOR memory. I really hope you could find the root cause of this issue and, ideally, solve it. Anyway, if you ever become able to reproduce systematically the faulty behavior and find out that the problem is related to our drivers, do not hesitate to recontract me. We could reopen this issue again.

Thank you for your contribution. We are looking forward to reading from you again.

With regards,