cancel
Showing results for 
Search instead for 
Did you mean: 

Issue regarding "generate peripheral initialization as a pair of '.c/.h' files per peripheral" using stm32wb55

Nicholas1
Associate II

After enabling "generate peripheral initialization as a pair of '.c/.h' files per peripheral" under Project manager > Code generator > Generated files, everything stops working, including debugging log also does not show up in my tera term.

How to regenerate this problem: (stm32wb55 ) 

  1. Select the BLE_Custom example from the library
  2. Add FreeRTOS in the ioc. file (Remember to set the TOTAL_HEAP_SIZE to 20480, Enable     USE_NEWLIB_REENTRANT  , change your SYS timebase source to TIM17)
  3. Go to Project manager > Code generator > Generated files
  4. Enable "generate peripheral initialization as a pair of '.c/.h' files per peripheral"

* There will be no issue if I did not enable the "generate peripheral initialization as a pair of '.c/.h' files per peripheral" but I feel that it is messy if I don't enable it.

1 ACCEPTED SOLUTION

Accepted Solutions
Semer CHERNI
ST Employee

Hello @Nicholas​ 

First let me thank you for having reported 😊

Actually you're right, I've been able to reproduce the same misbehavior from my side when using the same configuration as you.

I also tested the same setup but while disabling the "generate peripheral initialization as a pair of '.c/.h' files per peripheral" option, and it did worked fine.

I compared the generated code for both setting and I found that when the "generate peripheral initialization as a pair of '.c/.h' files per peripheral" option is enabled the "MX_APPE_Init();" is not generated which cause the problem.

When the "MX_APPE_Init();" is added just before "osKernelStart();" the project should run correctly.

With this being said, this problem is raised internally to be reviewed. I'll keep you posted with the updates.

Internal ticket number: 130851 (This is an internal tracking number and is not accessible or usable by customers).

Thanks for your contribution.

Semer.

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

2 REPLIES 2
Semer CHERNI
ST Employee

Hello @Nicholas​ 

First let me thank you for having reported 😊

Actually you're right, I've been able to reproduce the same misbehavior from my side when using the same configuration as you.

I also tested the same setup but while disabling the "generate peripheral initialization as a pair of '.c/.h' files per peripheral" option, and it did worked fine.

I compared the generated code for both setting and I found that when the "generate peripheral initialization as a pair of '.c/.h' files per peripheral" option is enabled the "MX_APPE_Init();" is not generated which cause the problem.

When the "MX_APPE_Init();" is added just before "osKernelStart();" the project should run correctly.

With this being said, this problem is raised internally to be reviewed. I'll keep you posted with the updates.

Internal ticket number: 130851 (This is an internal tracking number and is not accessible or usable by customers).

Thanks for your contribution.

Semer.

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.

Semer CHERNI
ST Employee

Hello @Nicholas​ 

The issue is fixed with the STM32CubeMx 6.7.0 available under this link.

Semer.

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.