removing chip cause unexplainable artifact.

[ulao]

I have a st chip (HT35) with the STM32H735G-DK Discovery Kit. Projects was complete and running fine. We then had to remove the OCTO SPI nor flash chip because we need access to Pe2. but after removing the chip the app froze after MX_TIM4_Init(). The solution was to put it at the end of the init process, and I'm hoping to find out why.

/* Initialize all configured peripherals */

 MX_GPIO_Init();

 MX_DMA_Init();

 MX_USART3_UART_Init();

 MX_ADC3_Init();

 MX_TIM1_Init();

 MX_UART7_Init();

<<WAS HERE>>

 MX_SPI5_Init();

 MX_DAC1_Init();

 MX_SPI4_Init();

 MX_TIM4_Init(); <-- now here

Anyone have a thought?

[Bob S]

Where "after the MX_TIM4_Init call" did it "freeze"? At the place where it "froze", what was the code trying to do? Basic debugging stuff.

[ulao]

Well that is just it, it does not matter. If I do this.

 MX_TIM4_Init();

 MX_SPI5_Init(); <--freezes, once I break the application its sitting int he SPI transmit.

 MX_DAC1_Init();

 MX_SPI4_Init();

If I do this.

 MX_TIM4_Init();

 MX_DAC1_Init();<--freezes in here, I didn't trace down where because it seems the TIM4 is causing the issue. If I try to step in the code claims it running but I get no step point. I had to stop the code to see where the address pointer was.

Timer 4 just had to be move last?

[ulao]

why does this even matter?

https://community.st.com/s/question/0D53W00000znZ7ZSAU/stm32cube-code-generator-bug-for-stm32g030j6

 and

https://community.st.com/s/question/0D53W00001HJ3EhSAL/wrong-initialization-sequence-with-cubemx-in-cubeide-when-using-i2s-with-dma

 and

https://blog.domski.pl/adc-initialization-order-bug-in-cubemx/

all of these are bugs in the IDE that put the inits in the wrong order. I'm not entirely sure why that even matters but beyond that why would the generation code do this?

more specific to my issue, why removing a chip causes this bug to show its face. I guess maybe the code generation was setup expecting the chip to be there and removing it caused the bug?

[LCE]

Well, that's the thing when using and relying on only/mostly CubeMX and HAL stuff, and not really knowing what's going on. And then come a CubeMX or HAL update...

Sorry for the rant...

So, debug step by step, look into the HAL functions, change some stuff into direct register control.

You'll learn a lot, and you will know (at least a little more) what's happening.

[ulao]

I agree with you on this one wholeheartedly but boss says use CubeMX and HAL so I have no choice. I personally hate abstraction.

the debug just does not work. It will not step in and died is like a never land state. Maybe I need to understand something here I'm missing but I can't fix what I can't find.

MX_TIM4_Init(); -- I can stp in here and go line by line.

 MX_SPI5_Init(); --it stops at this line, but step in goes nowhere.

[Bob S]

Ohhhhhh - THAT is new information. Could it be possible that you are getting constant TIM4 interrupts? Or a single TIM4 interrupt that doesn't get cleared so it keeps re-triggering?

Normally that wouldn't be the case as MX_TIMx_Init() don't usually start the timers so even if the timer interrupts are enabled it shouldn't generate any.

[ulao]

I don't think so but here inst the function.

static void MX_TIM4_Init(void)
{
 
 /* USER CODE BEGIN TIM4_Init 0 */
 
 /* USER CODE END TIM4_Init 0 */
 
 TIM_ClockConfigTypeDef sClockSourceConfig = {0};
 TIM_MasterConfigTypeDef sMasterConfig = {0};
 TIM_OC_InitTypeDef sConfigOC = {0};
 
 /* USER CODE BEGIN TIM4_Init 1 */
 
 /* USER CODE END TIM4_Init 1 */
 htim4.Instance = TIM4;
 htim4.Init.Prescaler = 10;
 htim4.Init.CounterMode = TIM_COUNTERMODE_DOWN;
 htim4.Init.Period = 250;
 htim4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
 htim4.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE;
 if (HAL_TIM_Base_Init(&htim4) != HAL_OK)
 {
 Error_Handler();
 }
 sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL;
 if (HAL_TIM_ConfigClockSource(&htim4, &sClockSourceConfig) != HAL_OK)
 {
 Error_Handler();
 }
 if (HAL_TIM_PWM_Init(&htim4) != HAL_OK)
 {
 Error_Handler();
 }
 sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
 sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
 if (HAL_TIMEx_MasterConfigSynchronization(&htim4, &sMasterConfig) != HAL_OK)
 {
 Error_Handler();
 }
 sConfigOC.OCMode = TIM_OCMODE_PWM1;
 sConfigOC.Pulse = 125;
 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;
 sConfigOC.OCFastMode = TIM_OCFAST_ENABLE;
 if (HAL_TIM_PWM_ConfigChannel(&htim4, &sConfigOC, TIM_CHANNEL_2) != HAL_OK)
 {
 Error_Handler();
 }
 /* USER CODE BEGIN TIM4_Init 2 */
	/*##-3- Start PWM signal generation in DMA mode ############################*/
	if (HAL_TIM_PWM_Start(&htim4, TIM_CHANNEL_2) != HAL_OK) {
		/* Starting PWM generation Error */
		Error_Handler();
	}
 
 /* USER CODE END TIM4_Init 2 */
 HAL_TIM_MspPostInit(&htim4);
 
}

[Bob S]

> I don;t think so

Don't "think", KNOW. Verify. What happens if you open disassembly view and use "step into"? You may need to enable the "instruction stepping" mode in the IDE (icon looks like an "i" with an arrow next to it).

FYI - you are starting the PWM before the GPIO pins are configured. Maybe not an issue, and probably not THIS issue. Also your comment says "starting pwm with DMA" but the code just starts PWM.

Try some standard debugging: comment out your "user code" in MX_TIM4_Init() and see if it makes any difference.

[Piranha]

> boss says use CubeMX and HAL so I have no choice

Show the boss this one:

https://community.st.com/s/question/0D53W00002Dvk8XSAR/bspaudiooutplay-never-finishes-and-blocks-execution

This is very frustrating, and since no real solution is in sight, my company decided to suspend the project and look for alternatives.

That is the price for clicking CubeMX and using HAL and other ST's broken bloatware instead of writing a decent code!