Problems migrating from STM32CubeMX 4.6 to 4.7 (and corresponding libraries.)

Posted on April 03, 2015 at 13:08

Hi HankB,

May be it will be more helpful for other users to track your feedbacks in separate discussions.

Thanks.

-Mayla-

Posted on April 04, 2015 at 12:57

Hi HankB,

                   I would like to see all the issues you discovered here in one post as I too am using MX 4.7 and Lib 1.5 for F4.

If someone then wants to discuss a separate issue then start a new thread for that particular issue.

Posted on April 07, 2015 at 07:08

When I migrated from 4.6.0 to 4.7.0 and to F4 1.5.0, the clock configuration panel got quite messed up, both in the configurator and in code.

I was able to take the settings from my old code and correct the configurator, which generated the same settings - until I quit and restarted - then I had to do a few corrections and save it again. After one extra iteration it settled down to a stable model.

Posted on April 07, 2015 at 12:09

Hi Andrei,

Is it possible to share the .ioc file that helps to reproduce your initial issue?

-Mayla-

Posted on April 08, 2015 at 03:40

More RCC issues on upgrade  from 4.6.0 to 4.7.0 and to F4 1.5.0.

My external 12MHz oscillator in a STM32F429VI will not start in 4.7 but had no issues with osc solution in previous versions. Had many crystal startup issues during bringup, gave up, and went to bypass w/osc. Working fine in 4.6. With new tools, same startup delay as XTAL and revert to HSI.

I did compare the code generated in 4.7 version with older version that worked with bypass osc:

- CubeMX clock  config page appears same as 4.6 working version.

- Main.c's SystemClock_Config(void) code is same as 4.6

- MANY differences between 1.5 and older, working version of stm32f4xx_hal_rcc.c

Wonder if I can just use older version of this file only?

Posted on April 09, 2015 at 01:26

Apparantly, my clock startup problem described in ''More RCC issues...'' post above is not due to new library.

Hate it when HW gets flaky at same time as SW upgrade.

Spent much time studying Ref Manual on STM32F4, checking registor settings, etc. etc.

Replace XTAL with oscillator on another prototype board (DIFFICULT!), it seemed to have LSE problem.

Went back to original board, after tweaking ''M'' so frequency into PLL is 1.5MHz instead of 1MHz, (Divide 12MHz by 8 instead of 12.)

Working now with latest library. 

Posted on April 09, 2015 at 14:06

Hi Folks,

Apologies for the delayed response. I was in the throes of a release last week and am now catching up.

I'll briefly outline the issues I encountered when migrating from 4.6 -> 4.7 and 1.4.0 -> 1.5.0. For anything that seems to persist I'll also start a new thread.

First of all, for anyone who seems puzzled that I'm talking about a release and platform upgrade in the same week, I am not really that reckless. ;) This is a preliminary (not fully functional) release. I had the back end code working but was having difficulty with the LCD display. It was decided to branch the code so we could deliver a 'blind' version and I could try anything including a tool chain upgrade to get the LCD working properly. The platform upgrade was not helpful but I eventually found that the issue was not LTDC settings but rather SDRAM settings. Somehow the FMC settings got changed and were not consistent with the SDRAM controller setup which resulted in screen jitter. I do not know how this happened so I am not listing it as an issue.

At the time of upgrade I found that a *lot* of settings reverted to their default value. Since then there are a number of issues that keep cropping up.

LTDC settings seem to be a real problem area. If I close and reopen the configuration page for that it seems like settings between X and Y axis get mixed up. I'm working with a display that is 480 wide x 800 high. Perhaps there is some test in the code that forces the aspect ratio to be wider than taller. It is also annoying that the tool limits the vertical height to 600. The manual for the part (STM32F429I) lists 768 as the maximum height so the limit at 600 seems arbitrary. (Yes, we are exceeding the spec for height but not pixel count and it seems to work.) I have more or less given up on the LTDC configuration and just put desired settings in a comment that survives code generation and I copy and paste it to 'that which shall not be changed' whenever I regenerate startup code.

The propensity for STM32CubeMX to eat opening braces has been defeated by:

#define OPENBRACE {
.
.
.
if( !x() )
OPENBRACE
if( tNow-ledTimer > heartbeatDelay )
OPENBRACE
if( heartBeatLEDisOn )
OPENBRACE

It looks crappy and confuses my editor's ability to indent properly but I do not have to replace the 9 opening braces that get deleted each time I update.

Asserts in SPI initialization code. This came up immediately following conversion and then went away until yesterday.

/* SPI2 init function */
void MX_SPI2_Init(void)
{
hspi2.Instance = SPI2;
...
hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLED;
HAL_SPI_Init(&hspi2);
}
HAL_StatusTypeDef HAL_SPI_Init(SPI_HandleTypeDef *hspi)
{
...
assert_param(IS_SPI_CRC_CALCULATION(hspi->Init.CRCCalculation));
// assert_param(IS_SPI_CRC_POLYNOMIAL(hspi->Init.CRCPolynomial));
...
#define IS_SPI_CRC_POLYNOMIAL(POLYNOMIAL) (((POLYNOMIAL) >= 0x1) && ((POLYNOMIAL) <= 0xFFFF))

So The generated code does not initialize the

CRCPolynomial

field and then fails the assert test since it is zero. IIRC there was a similar issue with timer configuration but that has not returned.

Following a recent regeneration I disabled USB OTG support when it was decided we did not need it. Following that the first compile failed because adc.h had not been copied. I also lost the interrupt on one of my timers.

I have attached .ioc files before the upgrade and also the most recent since (in addition to the upgrade it includes some other configuration changes.)

Thanks!

________________

Attachments :

GrooveGlove-4.6.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzU8&d=%2Fa%2F0X0000000bMb%2Fzx8ZNNKRtY9RcE3duPIitodumx0.lVgpAoDYjwrpcYk&asPdf=false

GrooveGlove-4.7.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzQL&d=%2Fa%2F0X0000000bMa%2FWL_KNBXzRS9R6MX0n_a1pR9_Pxr8nfGyYxUX62h6ySA&asPdf=false