Another problem compiling with CrossWorks 3.3

News, Setup, Compiling, Flashing, Development

Another problem compiling with CrossWorks 3.3

Postby HeliHenkie » Sun Dec 07, 2014 8:39 pm

Hi all,

I encountered another problem compiling my own firmware with CrossWorks 3.3.
Compiling stops at the following point in the process: Compiling stm32f4xx_cryp.c.

cryp.JPG


Did anyone encounter this problem and have a solution?

Best regards,

Jan Willem
The Netherlands
HeliHenkie
 
Posts: 93
Joined: Wed Oct 24, 2012 5:33 pm

Re: Another problem compiling with CrossWorks 3.3

Postby LPR » Sun Dec 07, 2014 8:58 pm

Read this recent thread. i might help.

viewtopic.php?f=31&t=3946&p=27852#p27847

Larry
LPR
 
Posts: 1323
Joined: Tue Jun 26, 2012 1:29 pm
Location: MN, USA

Re: Another problem compiling with CrossWorks 3.3

Postby Max » Sun Dec 07, 2014 9:03 pm

Don't need _cryp.c, exclude it from build (find in CW file list, r-click, exclude).

-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: Another problem compiling with CrossWorks 3.3

Postby HeliHenkie » Sun Dec 07, 2014 10:10 pm

@Max: Thanks for your reply. Why is this file in the project file if it isn't needed? What does it do?

Best regards,

Jan Willem
The Netherlands
HeliHenkie
 
Posts: 93
Joined: Wed Oct 24, 2012 5:33 pm

Re: Another problem compiling with CrossWorks 3.3

Postby Max » Sun Dec 07, 2014 10:20 pm

Jan, the project file simply includes everything in STM32F4xx_DSP_StdPeriph_Lib_V1.3.0/Libraries/STM32F4xx_StdPeriph_Driver/inc using a wildcard. It should really only include the ones we use specifically. I don't use CW often, and when I do I use a custom project file anyway.

You can see the actual StdPeriph driver files used in the Makefile:
Code: Select all
# STM32 drivers from STM32F4xx_StdPeriph_Driver/inc/
STM32_SYS_OBJ_FILES =  misc.o stm32f4xx_adc.o stm32f4xx_can.o stm32f4xx_dbgmcu.o stm32f4xx_dma.o stm32f4xx_exti.o stm32f4xx_flash.o stm32f4xx_gpio.o stm32f4xx_hash.o stm32f4xx_hash_md5.o \
   stm32f4xx_pwr.o stm32f4xx_rcc.o stm32f4xx_rtc.o stm32f4xx_sdio.o stm32f4xx_spi.o stm32f4xx_syscfg.o stm32f4xx_tim.o stm32f4xx_usart.o


Same with the CMSIS/DSP_lib ARM function libraries used (arm_*_f32.c).

Cheers,
-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: Another problem compiling with CrossWorks 3.3

Postby HeliHenkie » Mon Dec 08, 2014 6:57 am

@Max: Thanks for your clear answer. You state you don't use CW very often. Does that mean there is another way to compile the firmware? I've read about people trying to use alternative software on the forum, but I always thought this was without success.

Best regards,

Jan Willem
The Netherlands
HeliHenkie
 
Posts: 93
Joined: Wed Oct 24, 2012 5:33 pm

Re: Another problem compiling with CrossWorks 3.3

Postby Max » Mon Dec 08, 2014 8:32 am

Hi Jan. Yes, you can build from a command line w/out using the CW GUI. Angel describes it pretty well here: viewtopic.php?f=31&t=3114 You'll also need the zip file attached here: viewtopic.php?f=31&t=44&start=80#p17041 Also read the comments in the Makefile. :)

All the automated builds on our FTP server are scripted using `make Makefile`. I use Eclipse as my IDE, and configure build profiles I can launch for different configs (hw type, etc), which simply run `make Makefile` with various options.

BTW, in case you are trying to build a custom Quatos version (as per the other thread), you won't be able to w/out the (unreleased) quatos library file.

-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: Another problem compiling with CrossWorks 3.3

Postby HeliHenkie » Mon Dec 08, 2014 6:42 pm

@Max: Your assumption is spot on. I'd like to compile a custom Quatos version. I build the reference 400 quadcopter presented by Angel. My flight controller is a brand new AQ6 board with DIMU and 4 KISS esc's. I've read that it should be possible to adapt the code so that regular esc's can be used instead of the ESC32's. Apparently I've missed the part that a quatos lib file is required.
Will a firmware version with this modification be put on the FTP server?

Best regards,

Jan Willem
HeliHenkie
 
Posts: 93
Joined: Wed Oct 24, 2012 5:33 pm

Re: Another problem compiling with CrossWorks 3.3

Postby Max » Wed Dec 10, 2014 1:10 am

Jan, I'm not very clear on what is needed for non-ESC32 with Quatos. I know Steve and Menno have had some success with this, but the information is scattered or incomplete. Definitely some bleeding-edge stuff. Hopefully someone else will chime in on that on your original thread in the Quatos forums. Sorry I don't have more info for you.

-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: Another problem compiling with CrossWorks 3.3

Postby Kisssys » Wed Dec 10, 2014 4:37 am

Hi Jan,

Menno and I have been playing with this for a few month's with good success. It unfortunately had not been incorporated in the regular builds. Since the quatos library is not openly available even if you can compile the code your still missing the the most important part Quatos.

Hopefully these changes can be made in the near future.

The basic idea is to use the AQ to calibrate the esc's and then run a test program that steps the pulse width of the motor output from 1000 to 1950 us in 100 us steps. As it steps up we record the thrust available at each pw setting. From that we can plot a second order polynomial that represents the thrust for a given pw setting. The regular Quatos uses a rpm setting to the closed loop esc reference the thrust. Where we used to put the maximum RPM of the motor in MOT_VALUE_SCAL we use 950 since we plot the thrust curve from 0 to 950 us.

This is a 250 machine with Kiss esc's that fly's very well.
https://www.youtube.com/watch?v=cVXuUzmKDFg

Cheers
Steve
Steve
Kisssys
Kisssys
 
Posts: 1340
Joined: Sat Jun 23, 2012 9:23 pm

Next

Return to AQ Firmware

Who is online

Users browsing this forum: No registered users and 5 guests

cron