Unable to read reset values of the STM32H730VB OCTOSPIM peripheral. Unable to reconfigure OCTOSPIM peripheral. Silcon bad?
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.
