Some problems with STM32Cube after updating software

[Mick P. F.]

Hello,

I haven't used STM32Cube for a long time because I was busy with other things.

For software and hardware development I use STM32Cube under Linux and the board NUCLEO-H743ZI2 as hardware platform.

Since I wanted to create an project from scratch, I started with updates of the entire STM32Cube (STM32CubeIDE to 1.8.0 and the repositories to v1.9.1) before I started the project with the command "New STM32 Project from an Existing STM32CubeMX Configuration File (.ioc)". "ST-LINK" has also been updated to version "V3J9M3".

When setting up and editing the project, I proceeded as in the past.

1. Although I have activated and set up a SPI interfaces in the STM32CubeMX, which I called from the STM32CubeIDE, after generating code, the line '#include "spi.h"' is always missing in "main.c". I have to add it manually otherwise the compiler reports an error.

2. When debugging, the code always gets stuck in one of the hardware initialization calls: either in the procedure "SCB_EnableDCache()", "HAL_Init()" or others that follow them. If I go through these procedures step by step, the debugger sometimes doesn't hang. Even if I disable instruction and data cache in STM32CubeMX and regenerate the code, the debugger gets stuck in the "SystemClock_Config()" call in the line "if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)".

What is going wrong? Am I doing something wrong?

I am sending my IOC file in the attachment. Maybe someone can help me to find the error if I put one in there.

Thanks in advance,

Michael

[Peter BENSCH]

This is a known issue, already fixed in STM32CubeMX 6.5.0.

Stay tuned for the fix in STM32CubeIDE, too, which probably take a few more hours.

[edit]STM32CubeIDE 1.9.0 has just been released[/edit]

Regards

/Peter

[Mick P. F.]

Hello Peter,

I've updated the whole software IDE to 1.9.0, MX to 6.5.0 and the H7 repository to 1.10.0 by removing these components and installing them from scratch. I've also migrated my project, generated the code from MX again and ... the 1st problem disappeared but the 2nd problem with running and debugging persists as before.

Do you have any idea, how to solve it?

Thanks in advance,

Michael

[Peter BENSCH]

Since the second problem most likely has nothing to do with the first and can be solved with classic debugging, it would be best if you open a new thread for it. It is always much easier for other users to follow the topic if threads only deal with one problem.

Regards

/Peter

[Mick P. F.]

Hello Peter,

I disagree with this for the following reasons: I further examined the code with the debugger and found where it is stuck:

Previously, the procedure "StartDefaultTask()" was placed in the file "main.c", you should put your code there.

But now this function is missing in the file "main.c". That's why I put my code at the end of the procedure "main()" to see what happens at all. Through debugging I have now found that the procedure "StartDefaultTask" is in the file "${workspace_loc:/${ProjName}/Core/Src/freertos.c". It is called by the "osKernelStart()" and my code at the end of "main()" is never executed!

Is there a reason for the migration of this (important) procedure?

Kind Regards,

Michael

[Harvey White]

I noticed the same redirection. However, the start default task still calls the user code in my system (CubeMXIDE 1.9, but running under windows).

Specifically, this works and is called properly:

/* USER CODE BEGIN Header_StartDefaultTask */
/**
  * @brief  Function implementing the defaultTask thread.
  * @param  argument: Not used
  * @retval None
  */
/* USER CODE END Header_StartDefaultTask */
void StartDefaultTask(void *argument)
{
  /* init code for USB_HOST */
  MX_USB_HOST_Init();
  /* USER CODE BEGIN 5 */
  /* Infinite loop */
 
  TS_StateTypeDef TS_State;
 
  cpp_link();
 
  for(;;)
  {
	  osDelay(100);
  }
  /* USER CODE END 5 */
}

This is code for an F469I disco board, which had the USB enabled. cpp_link is a bridge program that calls programming to set up and generate C++ code with a FreeRTOS task embedded. Since cpp_link returns, the main loop is always running, even though it does nothing useful.

So this works for me.... Do you have the same structure? (not the cpp_link but the code in user area 5?

This has been working for several years, although I did check out whether or not code in the user area was called. It was, but more indirectly.

[Mick P. F.]

I'd like to know and to understand what is the reason for this change. Eventually I need to change all the old projects.

The "USER CODE 5" section, including the comment lines

/* USER CODE BEGIN 5 */
 
/* USER CODE END 5 */

is completely missing. Further down in the file main.c, in the procedure "assert_failed" there is the section "USER CODE 6" as in previous versions.

[Harvey White]

I'm somewhat puzzled. I've never had CubeMXIDE (or CubeMX) not generate that section unless I don't have FreeRTOS enabled.

I looked through the project options under project manager, and I have: Application Structure, advanced; Do not generate main() is NOT checked. Generate under root is checked without the option to change it. Under code generator: copy only the necessary library files, Keep user code when regenerating, Delete previously generated files when not regenerated, no templates, no HAL settings checked.

Under FreeRTOS options:

CMSIS_V2

I've looked through all the options, and I do think that it's possible you're missing the default task under Tasks and queues. If that isn't set, or it's deleted for some reason, then I can see problems, maybe.

Task name would be defaultTask, Priority would be osPriorityNormal, Stack size 4096, entry function: StartDefaultTask, code generation Default, Parameter NULL, Allocation: Dynamic, buffer name and control block both NULL

Under FreeRTOS Heap useage, you should see the Idle task, the Timer service task, and the default task.

Another option would be to add the user area 5 which should not be erased when regenerating code.

I've never had this problem, though.

As far as why the redirection, I can only speculate that FreeRTOS.org has changed how they do things, and adding the redirection may fit better with a newer structure, or the potential thereof.... No idea.

Good luck, though.