cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H730 outside of program code

Peaga
Senior

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!

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @Peaga ,

 

The issue is  fixed in STM32CubeMx 6.12.0 version.

 

Thank you.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

18 REPLIES 18
TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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!

Hello @Tesla DeLorean

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

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Peaga
Senior

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:

Pedro3_0-1691500661218.png

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

KDJEM.1
ST Employee

Hi @Peaga ,

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

KDJEM1_1-1692184925495.png

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.

KDJEM1_0-1692184687921.png

Could please check the AXI clock frequency value?

Thank you.

Kaouthar

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

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?

Pavel A.
Evangelist III

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