2021-04-20 02:54 PM
TLDR:
Using a debugger to read the values of the reset values for the OCTOSPIM->PCR registers fails.
Documentation:
RM0468 Rev 2 - Table 7. Register boundary addresses
0x5200B400 - 0x5200B7FF - OCTOSPI1 control registers Section 24.7: OCTOSPI registers
CMSIS stm32h730xx.c content
#define PERIPH_BASE (0x40000000UL) /*!< Base address of : AHB/APB Peripherals */
#define D1_AHB1PERIPH_BASE (PERIPH_BASE + 0x12000000UL)
#define OCTOSPIM_BASE (D1_AHB1PERIPH_BASE + 0xB400UL)
#define OCTOSPIM ((OCTOSPIM_TypeDef *) OCTOSPIM_BASE)
/**
* @brief OCTO Serial Peripheral Interface IO Manager
*/
typedef struct
{
__IO uint32_t CR; /*!< OCTOSPI IO Manager Control register, Address offset: 0x00 */
__IO uint32_t PCR[3]; /*!< OCTOSPI IO Manager Port[1:3] Configuration register, Address offset: 0x04-0x20 */
} OCTOSPIM_TypeDef;
Connecting a debugger, halting the CPU in the Reset_Handler before any code runs and inspecting the memory at the location results in the following:
Expected default values:
I'm unable to configure the OCTOSPIM peripheral on at least two CPUs.
1) STM32H730VBH6
2) STM32H730VBT6
I have two designs, one using the STM32H730VBH6 which uses OCTOSPIM data lines 0-3. The default configuration for the OCTOSPIM device allows it to work just fine.
The second design, using an STM32H730VBT6 uses OCTOSPIM data lines 4-7 for the flash chip and thus requires non-default configuration.
I verified the problem on BOTH designs. Any attempt to write or read to the OCTOSPIM periphal has NO EFFECT on both designs. Multiple PCBs built, all silicon has the same issue.
I *am* able to read other non-zero reset values using the debugger and other code, such as the defaults for the PWR control register 1.
Questions:
1) Is the base address correct?
2) Is the silicon bad?
3) Why is the length of OCTOSPIM_TypeDef->PCR et to 3, in the HAL code. When there are only TWO PCR registers.
4) What's the solution/workaround?
I checked the errata but there is currently no mention of this problem.
Solved! Go to Solution.
2022-01-29 04:45 PM
It is 2022 and HAL_RCCEx_OCTOSPIDelayConfig is still missing from the H7 HAL library version 1.91. This is so unfortunate. I bought a dev kit for a project and I cannot get the OSPI_HyperRAM_MemoryMapped mode working.
2023-10-27 06:22 PM - edited 2023-10-27 06:28 PM
Imagin it beeing end of 2023 and the issue is still present as if nobody actually cared.
2023-10-28 05:32 AM - edited 2023-10-28 05:33 AM
2023-10-28 05:47 AM
@Pavel A. Indeed I have seen these parameters. My impression was that these parameters are for Bypass the Delayblock and the other to enable a fixed 1/4 cycle delay. I thought that IFF the delay block is NOT bypassed, there should be a way to configure it more granular than just 1/4 cycle... At least that seemed to be the statement in AN5050.
For me the hyperbus interface has so far been a nightmare to implement as documentations are not matching up, examples are sparse and ST really does not help in any way.
2023-10-29 09:30 AM
>I thought that IFF the delay block is NOT bypassed, there should be a way to configure it more granular
Try to ask a new question. Exactly this one ^
2024-05-11 09:39 AM
This is so bad, that years after I still find no mention in all the STM tutorials, presentations, videos - simply nowhere IOMNGREN is mentioned. Please address this soon!
Also, see here: https://community.st.com/t5/stm32-mcus-products/register-bits-missing-in-stm32cubeprogrammer/m-p/673018/highlight/true#M243865.
2024-12-01 10:02 PM
Hey Guys,
It's now 12/02/2024, and the problem still exists. I guess nobody at STM cares about the issues brought forward here.