Unable to read reset values of the STM32H730VB OCTOSPIM peripheral. Unable to reconfigure OCTOSPIM peripheral. Silcon bad?

[dominicc]

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.

[Andreas Bolsch]

Clock for OCTOSPIM enabled? The name is somewhat misleading: IOMNGREN in RCC_AHB3ENR.

[dominicc]

Hi Andreas,

The OCTOSPIM does not have a clock. OCTOSPI has a clock. The issue is with the OCTOSPI MANAGER peripheral, not the OCTOSPI peripheral. Regardless of clocks, reading/writing the OCTOSPIM registers should be possible, but reads/writes to the documented registers has zero effect.

As noted, on one of my designs for which the default configuration of the OCTOSPIM periphal does not need changing, the OCTOSPI peripheral also works and I'm able to use Winbond 16MB QuadSPI flash chip via the NCS/CLK/IO0-3 GPIO lines.

[Andreas Bolsch]

Yes, I know that you're referring to OCTOSPI*M*, not the OCTOSPI. And no, it does defintitely have a clock for register accesses, from the RM:

"Bit 21 IOMNGREN: OCTOSPI I/O manager clock enable

Set and reset by software.

0: OCTOSPI I/O manager clock disabled (default after reset)

1: OCTOSPI I/O manager clock enabled"

[Andreas Bolsch]

Just remembered that:

https://community.st.com/s/question/0D50X0000C8chyCSQQ/rm0455-where-is-octospim-clock-enable-bit-in-stm32h7ab-

[dominicc]

Further to this I created a tool to scan the entire peripheral address space for known peripheral register addresses.

https://gist.github.com/hydra/f2cffb9e590ec7a203c0ff3b6462c051

The tool does *NOT* find the value for the OCTOSPIM_P1CR or OCTOSPIM_P2CR in the documented peripheral address space.

In these screenshots the breakpoint is at the end of the scan, the searchAddress reached the end of the peripheral address space.

Given this, I currently conclude that the OCTOSPIM peripheral cannot be accessed in the MCU and that there's a silicon bug.

[dominicc]

ok, I'll double check that, thanks!

[dominicc · Accepted solution]

 

Success!

Thanks a million for point me at that register, I doubt I would ever have found it.

The workaround/solution is:

RCC->AHB3ENR |= RCC_AHB3ENR_IOMNGREN;
...
  if (HAL_OSPIM_Config(&hospi1, &sOspiManagerCfg, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

This issue highlights that:

• The ST MCU documentation is incomplete.
• The HAL/CMSIS libraries are missing clock enable code.
• The CubeMX generated code does not enable the clock which is *required* prior to any call to `HAL_OSPIM_Config`

[dominicc]

Success. After enabling the clock​ as per the solution in my post above I was able to use the flash chip on the IO4-7 lines in memory mapped mode.

Thanks again for the replies Andreas!​

[dominicc]

I created a case with ST tech support, reference 00130370 and made the following recommendations of things that need fixing:

1 - CubeMX code generation - the clock for the OCTOSPIM peripheral is not enabled.

2 - AN5050 Octo-SPI interface on STM32 microcontrollers should be updated, Section 3 does not mention that the clock needs to be enabled prior to use.

3 - RM0468 The block diagram for the OctoSPIM 26.3.1 should have the CLOCK signal drawn on it.

4 - RM0468 26.3.2 should have a note added to it that the clock must be enabled before the registers can be accessed. For other peripherals there a set of steps given for correct operation, this would be useful.

5 - RM0468 8.7.27/8.7.39 should be updated so it includes the word 'OCTOSPIM' so that a search of the documentation reveals it easier. e.g. 'IOMNGREN: OCTOSPIM clock enable'

6 - Other reference manuals for the other H7 CPUs should also be updated in the same way, as they all have the same issue.

7 - The code examples in the STMCubeH7 package need updating. I could not find any reference to the IOMNGREN in them so it appears none of them enable the clocks, e.g. examples: OSPI_HyperRAM_MemoryMapped, OSPI_NOR_MemoryMapped_DTR for the STM32H735G-DK among others.

8 - The OCTOSPI HAL Delay Block code is not enabled when then the OSPI module is enabled.

stm32h7xx_ll_delayblock.c

should be changed to

    #if defined(HAL_SD_MODULE_ENABLED) || defined(HAL_QSPI_MODULE_ENABLED) || defined(HAL_OSPI_MODULE_ENABLED)
    ...
    #endif /* (HAL_SD_MODULE_ENABLED) || (HAL_QSPI_MODULE_ENABLED) || (HAL_OSPI_MODULE_ENABLED)*/

 9 - HAL_RCCEx_OCTOSPIDelayConfig is missing from the H7 HAL library. AN5050's example of delay block configuration cannot be used on the H7.

10 - Update AN5050 to Provide an example of Delay block configuration using the H7 LL driver.

I'm hoping to see some documentation and code revisions based on my suggestions.