STM32CubeIDE 1.14.1 deletes code from USER CODE BEGIN/END block

[Andrei Chichak]

I have a project for STM32L452 using ThreadX and USBX, CubeIDE 1.14.1, firmware L4 1.18.0, on MacOS 14.3.1 Sonoma on Intel i9.

In USBX/App/ux_device_descriptors.h I have placed some code:

/* Private defines -----------------------------------------------------------*/
/* USER CODE BEGIN Private_defines */
extern uint8_t serialNumber[];
/* USER CODE END Private_defines */

Ignore those line numbers, the real numbers are 264-267.

When I go into the GUI and change my USB PID to something new, save, and regenerate the code, the Private_defines block is now empty:

/* Private defines -----------------------------------------------------------*/
/* USER CODE BEGIN Private_defines */

/* USER CODE END Private_defines */

So, for experimenting, I deleted the .h file and had the GUI regenerate the .h file from scratch, just to make sure that I hadn't put in anything that wasn't in the stock BEGIN/END guards, and the regen deleted my code again. Yes, this can be duplicated.

Here's a hint for you all (the walrus was Paul), the same Private_defines block is also generated at lines 248-251.

Here's another hint; if I put my code in the first Private_defines block, after the regen, my code gets pasted into BOTH Private_defines blocks.

That is all,

Andrei (from the Great White North)

[CMYL]

Hi @Andrei Chichak 

I tried it by inserting some declaration in a dac.h file, but not able to reproduce it after generation. The workstation and the OS are different .... 

To escalate the issue to STM32CubeMx/STM32CubeIDE development team, it is better to share the *.IOC MX project file. 

If possible also to share with me the STM32CubeMx version.

One more question please, does the issue is seen only in USBX/App/ux_device_descriptors.h file or any other *.h file ?

Best regards,

[Andrei Chichak]

When taking a car to a mechanic, it's best to just describe the symptoms rather than tell the tech what to replace.

In this case, I see the problem in ux_device_descriptors.h, but the same pattern could be in many generated files. If I was to tell the CubeIDE team to fix ux_device_descriptors.h, they may not look into all generated code files to see if any other BEGIN/END blocks are duplicated, and fix those files too.

I can't tell you which CubeMx version is involved, is there some place in CubeIDE that I can poke to get that info?

If you wish, I can put together a sample IOC file that shows the issue. The IOC file in question is for a device that hasn't been released to market yet and it'd be imprudent to send out that information without an NDA in place.

[Andrei Chichak]

Here is a mostly broken project that I just threw together that shows the issue.

[Andrew Neil]

---

@Andrei Chichak wrote:

/* Private defines -----------------------------------------------------------*/
/* USER CODE BEGIN Private_defines */
extern uint8_t serialNumber[];
/* USER CODE END Private_defines */

---

Although it does seem hard to believe that it's relevant, that's not a define!

[Andrei Chichak]

Nobody expects a Spanish Code Review!  (Monty Python reference)

[CMYL]

Thank you @Andrei Chichak for the project,

I'm totally agree, we need to describe the symptom in order to fix it in all similar files.

Using your shared code I reproduced the 2 issues you described above.

No idea about how the code generator is implemented, but it seems like at each generation, the Mx tool replaces the file by the one in the USBX pack (~\STM32Cube\Repository\Packs\STMicroelectronics\X-CUBE-AZRTOS-L4\2.0.0 ..).  Before replacement, the parser checks first if any code is written in between the meta-comments, it is then stored to rewrite it into the new replaced file.

- In case 1, nothing found in the first meta-comment instance (lines 249-251), assuming the parser stops at the first instance found. So when generating the code, nothing is written in each instance of the meta-comment (assuming the parser is updating all the instances when restoring the  content). 

- In case 2, similarly as in case 1, what was found in the first instance, is written to all the instances.

To correct this bug, I think we need to keep only one instance of meta-comment. If more than one instance needed we can do like in the main.c (/* USER CODE BEGIN 0 */  .... /* USER CODE BEGIN 1 */)

I will submit this bug to the development team for correction, hope my analysis is correct.  Any way, I'll keep you aware about the status.

Thank you again for the basic firmware reproducing the issue. I will delete it from this discussion to avoid any leakage 😉

Kind regards,

Younes

[Andrei Chichak]

@CMYL thanks for the quick response.

That test code is just trash (as you likely know). No use keeping it since it will just confuse anybody that downloads it in the future.

I figured the generated file is just template code pulled from the firmware distros, with name keyed BEGIN/END blocks, which would explain the duplication of the first block (which looked like deletion, but actually copying of a blank block).

The trick will be to write a script to pull out all of the BEGIN/END block names and run them through uniq to see if there are anymore duplicates. ST has a lot of firmware distros with lots of files in each. I can't imagine that this is unique.

Thanks again,

Andrei (enjoying the nice weather before it goes back down to -25C next week)

[CMYL]

Hello @Andrei Chichak 

Following your question I created 2 requests to correct the issue. One for STM32CubeMX and the second for middelware teams. Thanks I suggested your idea to detect all duplication. I suggested also to add a tolerance feature to the Mx tool to support duplication, in case some corner cases are not detected. The idea is to consider the duplication as 2 separate child comments. 

I put the ticket number here for internal tracking purpose, not possible to access for you.

Ticket 174500 Submitted

Ticket 174506 Submitted

___________________________________________________________________________________

PS: when your question is answered, please close this topic by clicking "Accept as Solution".

Best regards,

Younes