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=falseGrooveGlove-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
