Migration from STM32Cube FW_G4 V1.5.1 to STM32Cube FW_G4 V1.6.0

[JLojo]

Hi there,

What are the secret steps for migrating a project to STM32Cube FW_G4 V1.6.0 in a clean way?

I had an operational project built with STM32Cube FW_G4 V1.5.1 (CubeMX 6.10.0) and running properly for years!

Since I updated Cube IDE I was prompted to migrate the project,and stupidly, I accepted! :(

And now, this is a big mess, at least with the timers and uart interface... (probably due to interrupt issues).

After spending 2 full days (and nights) I've still not been able to find what was wrong.

But I've been able to reproduce the issue on my old dying laptop, where the project was still not updated, and it was perfectly running. I just added a GPIO toggle on each sys-timer interrupt and got a perfect square wave with two milliseconds period (one transition on each interrupt). I just updated the FW package and then it looks like tachycardia...

I carefully checked the NVIC settings on both sytems, but they look very similar.

Anyway, the IOC differ only by the firmware package revision and Cube MX version...

Any advice welcome!

Thanks

JYL

[TDK]

Most straightforward way is to diff the current code vs the code that worked.

Consider debugging it from the aspect of "what's wrong" instead of the aspect of "what changed in HAL to break this?" What is wrong with the timers and uart in particular that isn't working?

[JLojo]

Thanks TDK for the advice...

Attached are 2 screen shots of the scope:

Blue curve is the GPIO line that is toggled on each interrupt of the SYS-timer; yellow one corresponds to timer15 sets to a one millisecond period as well.WorkingNot Working

When not working, the duty cycle of the sys-timer is different at each run of the MCU, and the behavior of the tiumer15 changes as well: sometimes it gets 1 ms period as expected, sometimes it goes to 2 ms (as it is on the graph)!

it really looks like something is not well initialized somewhere.

However, after running a WinmMerge between the original and updated project, besides the content of .\Drivers\STM32G4xx_HAL_Driver\Src\ in which all files differ, the content of the generated files are strictly identical in both cases (except sometime for some blank characters!).

Only noticeable difference, in the spi.c generated file: the data size which was set by default to SPI_DATASIZE_8BIT arrives now with SPI_DATASIZE_4BIT! but this has nothing to do with the issue observed (SPI is not used at the moment ;)

Concerning the UART, the symptom is that we get only one character out of ... several... (interrupt not received)

@st team, it would be much appreciated that when CudeIDE suggest a migration of a project, there is a clear notice of the fundamental changes made to the new release to guide us in order to adapt our code, if necessary. Even better, if new features have been introduced requiring to change the autogenerated source files, it would be nice that those autogenerated files are automatically updated to be operational!

JYL