Posted by Vetch on 2017-02-21 09:53

Hello,

I just did the following test to play with the F7 BSP example on the F746 Discovery :

- I downloaded the F7 Cube FW package V1.6.0;
- I launched SW4STM32 V1.13.1;
- I am leasy so I selected the workspace within the Cube package :
...\STM32Cube_FW_F7_V1.6.0\Projects\STM32746G-Discovery\Examples\BSP\SW4STM32
- Right-click in the Project Explorer window >> Import >> General >> Existing Projects into Workspace >> Next >> Browse >> Select the project folder :
...\STM32Cube_FW_F7_V1.6.0\Projects\STM32746G-Discovery\Examples\BSP\SW4STM32\STM32746G_DISCOVERY folder >> Finish
- Right-click on the project >> Properties >> C/C++ Build >> Enable parallel build >> Apply >> OK
- Right-click on the STM32746G_DISCOVERY project >> Properties >> C/C++ General >> Indexer >> Enable project specific settings >> Remove the Index unused headers >> Apply >> OK
- Right-click on the STM32746G_DISCOVERY project >> Build Project
- Plug the F746 Discovery board;
- Right-click on the STM32746G_DISCOVERY project >> Debug As >> Ac6 STM32 C/C++ Appplication

.... and it works well and the example is fun ...

Posted by saburo on 2017-02-21 15:28

Yes thanks, that works for me too, I actually started with that (except I created a separate worksspace, but the result is the same).

My issue is when I start a project with STM32CubeMX, I was trying not to include the whole shebang of the BSP, instead I was focusing on single components to better understand and learn.

I started with the display (not the easiest, I reckon, but a good start to ease debugging), enabled LCD and DMA2D in HAL then I understand I need to include the BSP libraries in my project, from ST4.

But then if I include stm32746g_discovery.h or the other BSP includes things start to go south.

So far this is where I got (in my main.h) :

/* USER CODE BEGIN Includes */
// HAL main

1. include “stm32f7xx_hal_def.h” // should not be needed, but cannot find HAL_StatusTypeDef
2. include “stm32f7xx_hal.h”

// HAL components

1. include “stm32f7xx_hal_dma.h”
2. include “stm32f7xx_hal_dma2d.h”
3. include “stm32f7xx_hal_uart.h” // needed somewhere, whatever, no big deal
4. include “stm32f7xx_hal_sdram.h”
5. include “stm32f7xx_hal_ltdc.h”
6. include “stm32746g_discovery.h”

// BSP components

1. include “stm32746g_discovery_lcd.h”
2. include “stm32746g_discovery_sdram.h”

// LCD specific component

1. include “rk043fn48h.h”

/* USER CODE END Includes */

And I still get :
.../stm32f7xx_hal_rcc_ex.h:3206:1: error: unknown type name ‘HAL_StatusTypeDef’
../stm32f7xx_hal_dma.h:162:3: error: unknown type name ‘HAL_LockTypeDef’

etc

but both are defined in “stm32f7xx_hal_def.h” which I added before anything else!

Anyhow, I agree the demo works and it’s pretty cool

Posted by HankB on 2017-02-22 14:43

I’m headed down the same path. (Brilliant minds think alike! )
Have you looked at stm32f7xx_hal_conf.h? It seems like ST uses that to enable various HAL modules. MX will uncomment some of the defines near the beginning of this file but not all required for the BSP. I found I had to enable HAL_SDRAM_MODULE_ENABLED manually.HAL_StatusTypeDef is pretty fundamental and I cannot imagine why that’s coming up undefined.

I also ran into the problem with the UART. I included some logging file and I suspect it might support logging to a UART. I resolved that issue by configuring UART6 in MX.

Otherwise I’ve just been copying files to my project directory as needed. I’ve been wondering if it is better to do that or add he BSP files as external references. For this project thsy should not require modification.

Posted by HankB on 2017-02-22 15:56

I’ve just put my project up on Github: https://github.com/HankB/STM32F7explore (Hopefully I have all of the licensing stuff straight. ;) )

At the moment I’m wrestling with functions in lcd_log.c not being resolved. I’vce added that file to the project directory tree (.../Utilities/Log/lcd_log.c) but so far Eclipse is refusing to compile it for reasons I do not understand. It shows up in the project browser but a build produces no object file.

Posted by saburo on 2017-02-22 21:41

Uhm, I see from your project you are adding freeRTOS, LWIP... I am trying to keep it as minimal as possible.

Your project seems to be in a better shape than mine tho.

The main difference between your approach and mine is that, from your cube project, I see you left all the pins assinged, while I unassigned them
“I tried to create a project with CubeMX, unassigned the pis, then added LTDC and DMA2D (whcih I think it is used by the display drivers). ”

I think if you keep the default discovery setup in cubeMX, you end up adding all the stuff by default, which is what I am trying to avoid

But I am breaking my head on the different error mesages I get... I really do not understand how those dependencies are resolved.
You had a good point there about the commented defines in HAL_conf, actually I worked around by including the needed modules in main.h, but I could have achieved the same (and in a cleaner way) by uncommenting the needed defines at the beginning of stm32f7xx_hal_conf.h.

I am not really sure what the procedure is supposed to be when you create a new project for the descovery, starting from cubeMX and also I think it’s a pity cube does not have an option to add the BSP needed drivers, the same way you do with middlewares.
In kyle and IAR it seems a bit easier to do : you get them as available packages for your project, select them and: boom, you have them with supposedly the needed includes and stuff.

Posted by HankB on 2017-02-23 03:34

Right, FreeRTOS and LwIP are things I wanted right off the bat. I had them in before I tried adding LCD support.

I think that MX configures a bunch of peripherals that are commonly used on this board. I did not change any of that since it caused no difficulty (save longer compile times.)

At present I’ve resolved the issue with unresolved externals (and multiply defined externals) and the project on Github builds. I may have a regression though as DHCP does not seem to be working. I thought that was working before I added LCD.

I haven’t tried anything with touch either.

I think adding board support is a future goal for MX, but I don;t know what the priority is. Keep in mind that MX is often used for custom boards where the board support will need to be hand coded or highly modified from the samples.