removing chip cause unexplainable artifact.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-09 7:48 AM
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?
- Labels:
-
OctoSPI
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-09 11:33 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-09 11:38 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 6:35 AM
why does this even matter?
https://community.st.com/s/question/0D53W00000znZ7ZSAU/stm32cube-code-generator-bug-for-stm32g030j6
and
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 8:58 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 9:08 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 10:21 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 10:36 AM
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);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 10:44 AM
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-10 4:34 PM
> boss says use CubeMX and HAL so I have no choice
Show the boss this one:
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!
