Problems porting from STM32f407 Discovery to STM32F429 Discovery

[alberto239955_stm1_stmicro_com]

Posted on May 11, 2015 at 18:37

Good afternoon,

I am trying to port an application I wrote for the STM32F407 Discovery board, which makes use of the ADC, DMA and NVIC to the STM32F429 Discovery board. I receive a lot of errors when compiling, it looks like many things changed from one board to the other... for example in this snippet of code:

NVIC_InitTypeDef NVIC_InitStructure;
ADC_CommonInitTypeDef ADC_CommonInitStructure;
/* Enable peripheral clocks */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_DMA2, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1 | RCC_APB2Periph_ADC2, ENABLE);
/* Configure Interrupt Controller for DMA requests */
NVIC_InitStructure.NVIC_IRQChannel = DMA2_Stream0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

I receive these errors : Globals.h(52): error: #20: identifier ''NVIC_InitTypeDef'' is undefined Globals.h(55): error: #20: identifier ''ADC_CommonInitTypeDef'' is undefined and many, many others... those are just an example. It looks like the porting is not so straightforward... Does anybody have words of wisdom on how to proceed ? Thanks Alberto

[Tesla DeLorean]

Posted on May 11, 2015 at 21:01

Wouldn't that just be indicative of not having the USE_STDPERIPH_DRIVER  define passed to the compiler?

The model is to #include ''stm32f4xx.h'' directly, or via the disco variant, which in turn pulls in your project local stm32f4xx_conf.h, which pulls in the specific peripheral includes.You'd also want the processor define as STM32F429_439xx vs STM32F4XXThe only real bump should be the FMC vs FSMC

[alberto239955_stm1_stmicro_com]

Posted on May 11, 2015 at 22:12

Clive,

   thanks for your answer. The problem is that the define USE_STDPERIPH_DRIVER actually IS defined... as is the processor STM32F429_439xx... using here the Keil uVision IDE, and I have just checked for those settings... probably the way to go is to use STM32CubeF4 with its APIs. Do you have feelings about that ? Thanks Alberto

[Tesla DeLorean]

Posted on May 11, 2015 at 23:01

Do you have feelings about that ?

Just bad ones. Cube/HAL adds a lot of bulk, and little value. I like my peripheral abstractions to be thin and clean.I guess you'd want to look at the dependency tree Keil creates for the files, ie which includes are coming from where, and that they are coherent. If it's not pulling the ST SPL ones you'll have a problem. Here you'd need to review the Include Paths the compiler uses for the project.I've really had no headaches moving stuff from STM32F4-DISCO to STM32F429I-DISCO boards in Keil 4.7x.

[alberto239955_stm1_stmicro_com]

Posted on May 13, 2015 at 00:55

You are quite right... I am having problems, as I need to use the touch screen with the emWin libraries, and this implies the use of some functions of the STM32Cube. Naturally, the includes of STM32Cube are not compatible with those of the STM32F4xx_DFP library of Keil... same name, contents different.. a real nightmare.

Open to any suggestions... TNX ALberto