STM32H730 outside of program code

[Peaga]

Hello!

I'm porting a working code from H750VB to H730VB, generating a new HAL core from STM32CubeMX, but right after entering on "SystemClock_Config" function at debug mode, I've got the message "Break at address 0x46bd3718 with no debug information available, or outside of program code". Going step-by-step, the issue happens on "HAL_RCC_ClockConfig", at the second "D1PCLK1 configuration" calling:

if ((RCC_ClkInitStruct->APB3CLKDivider) < (RCC->D1CFGR & RCC_D1CFGR_D1PPRE))
{
 assert_param(IS_RCC_D1PCLK1(RCC_ClkInitStruct->APB3CLKDivider));
 MODIFY_REG(RCC->D1CFGR, RCC_D1CFGR_D1PPRE, RCC_ClkInitStruct->APB3CLKDivider);
}

I'm using the same custom board and pinout as H750 one and the app is quite simple: a few GPIOs, UART and SPI. I've also tried just a "blink LED" code, same break on "SystemClock_Config". Two different boards, same issue.

Did anyone face the same problem?

Thanks!

[TDK]

Check that the relevant registers are the same on each device and/or make sure you're including the correct "stm32h7xxxx.h" include file for the H730.

[Peaga]

Hello @TDK, thanks for your prompt response

Yep, the registers are correct, all pointing to "stm32h730xx.h". At the porting process, I've generated a new design at CubeMX and after compiling it, I've compared the original files, one by one!

[Tesla DeLorean]

The H720 is a different IC from the one used for the H743/H753/H75x parts, they are not all the same, and as @TDK indicates this needs different registers and include files to be pulled in.

Perhaps create a NEW H730 project and port / merge in your existing code where it is not dependent on the IC / MCU. Especially things like clocking, buses, and memories, etc.

[Peaga]

Hello @Tesla DeLorean

Yes, that's what I did! All H730 project was created by CubeMX from 0.

[Tesla DeLorean]

The errant address could come from stack or errant pointer. Double check VCAP capacitors/voltages, and FLASH wait states as being appropriate for clocking speed. Check interrupt vectors that could point to these addresses.

[Peaga]

Hello again

It turns out the problem was with the FLASH latency. For some reason, the CubeMX set it to 0 instead of 1 (I'm working at 100MHz), also disabling the option on GUI:

Changing it on code, now the board is starting. Is it a CubeMX bug?

[KDJEM.1]

Hi @Peaga ,

The Number of wait states (LATENCY) depends from the AXI Interface clock frequency and VCORE range as shown in RM0468  table 16.

How much the frequency of AXI peripheral are you using in your clock configuration?

Note that, It mentioned in the datasheet (table12) that the maximum AXI clock frequency for VOS3 is 85 MHz.

Could please check the AXI clock frequency value?

Thank you.

Kaouthar

 

[Peaga]

Hello Kaouthar, I'm realy sorry for delayed response.

AXI clock is set to 100 MHz and the "Power regulator voltage scale" set by Cube is "3". So, according to the datasheet, this option should be anything but "3", as the AXI is 100, right?

[KDJEM.1]

Hi @Peaga ,

Thank you for updating post.

I made some tests using STM32H730VBHx MCU  and STM32CubeMx 6.10.0 revision and I'm not able to reproduce the issue.

For STM32H730VBHx MCU and when the AXI clock is set to 100MHz, the STM32CubeMx 6.10.0 disactivates  "Power Regulator Voltage Scale 3" option as shown in the below figure:

Which STM32CubeMx version are you using? Could you please update the latest version of STM32CubeMx tool?

Could you please share your ioc file?

Thank you.

Kaouthar

 

[Pavel A.]

Why is VOS3 selected when VDD is 3.3V ? Is the supply voltage 3.3V indeed?

[Peaga]

That's a good question, I've thought that option was auto selected by Cube depending on clock configuration (and yes, VDD = 3v3). When I change the main clock to 400 MHz, for example, I can only select VOS0 or VOS1.