STM32CubeMX与编译调试问题



STM32CubeMX确实是个好东西，可以协助开发者快速搭建应用开发平台。但与IDE的配合上，存在一些问题。比如：

1. 使用STM32CubeMX自动生成工程代码后，都要全部重新编译。
2. 使用MDK编译STM32CubeMX自动生成的工程代码时，编译速度巨慢。
3. 某些版本IAR编译调试STM32CubeMX自动生成的工程，会有一些问题。

一. 全部重新编译的问题

这个问题，应该跟STM32CubeMX自动生成工程的头文件包含设计有关系。HAL层、某些中间件的头文件都被包含在了main.h头文件中。

二. MDK编译的问题

MDK编译巨慢的问题，太影响开发效率了，再加上第一个问题，基本上确定放弃使用MDK进行开发了。此外，在使用MDK5的过程中，还遇到了下面几个问题。

KEIL5编译链接问题#1：

直接使用MDK编译STM32CubeMX自动生成的工程代码时，编译时出现如下错误：

..\Middlewares\Third_Party\FreeRTOS\Source\portable\RVDS\ARM_CM4F\port.c(483): error: A1586E: Bad operand types (UnDefOT, Constant) for operator (

这个问题需要修改下代码才能解决。

在port.c 483行，有代码如下：

	/* Save the new top of stack into the first member of the TCB. */
	str r0, [r2]

	stmdb sp!, {r3}
	mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
	msr basepri, r0
	dsb
	isb
	bl vTaskSwitchContext
	mov r0, #0
	msr basepri, r0
	ldmia sp!, {r3}

#configMAX_SYSCALL_INTERRUPT_PRIORITY定义如下：

/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 	( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

configPRIO_BITS定义如下：

/* Cortex-M specific definitions. */
#ifdef __NVIC_PRIO_BITS
 /* __BVIC_PRIO_BITS will be specified when CMSIS is being used. */
 #define configPRIO_BITS         __NVIC_PRIO_BITS
#else
 #define configPRIO_BITS         4
#endif

__NVIC_PRIO_BITS定义如下：

/**
  * @brief Configuration of the Cortex-M4 Processor and Core Peripherals 
  */
#define __CM4_REV                 0x0001U  /*!< Core revision r0p1                            */
#define __MPU_PRESENT             1U       /*!< STM32F4XX provides an MPU                     */
#define __NVIC_PRIO_BITS          4U       /*!< STM32F4XX uses 4 Bits for the Priority Levels */
#define __Vendor_SysTickConfig    0U       /*!< Set to 1 if different SysTick Config is used  */
#define __FPU_PRESENT             1U       /*!< FPU present                                   */

问题应该归结于__NVIC_PRIO_BITS的定义。在main.h文件的/* USER CODE BEGIN Private defines */位置添加如下代码即可解决此问题。

/* USER CODE BEGIN Private defines */
#if 0
#ifdef __NVIC_PRIO_BITS 
#undef __NVIC_PRIO_BITS 
#define __NVIC_PRIO_BITS      4 
#endif 
#endif
/* USER CODE END Private defines */

KEIL5编译链接问题#2：

编译链接时出现如下错误：

runtime error R6002 floating point support not loaded

根据http://www.openedv.com/posts/list/49274.htm说法，是电脑中毒导致的。用杀毒软件查了下，果然电脑中毒了。查杀病毒，卸载KEIL5并重装，解决问题。

KEIL5编译链接问题#3：

.\STM324xG_EVAL\STM324xG_EVAL.axf: error: L6047U: The size of this image (60876 bytes) exceeds the maximum allowed for this version of the linker

这是因为KEIL重装后没有破解的缘故。重新破解下就OK了。

三. IAR编译调试的问题

1. IAR6.3版本

最开始使用IAR6.3版本，直接编译STM32CubeMX自动生成的工程时，因没有设置芯片型号导致编译错误。而且使用J-LINK调试时，也有许多问题。

2. IAR8.2版本

下载了最新版本的IAR，首次打开STM32CubeMX自动生成的工程时，有设置芯片型号，但是设置的芯片型号与在STM32CubeMX选择的芯片型号有点点对不上。比如，我在STM32CubeMX选择的芯片型号是STM32F407VE，而在IAR中却是STM32F407ZG。

除此外，最大的问题在于使用J-LINK调试时存在头痛问题，导致调试不顺畅。

问题#1：

使用J-LINK调试时，运行一会儿，经常出现如下图所示错误：Failed to get CPU status after 4 retries Retry?

问题#2：

IAR下载程序提示：The connected J-Link is defective,Proper operation cannot be guaranteed…….

把IAR 8安装目录下的JLINK驱动换成IAR6.3版本驱动，不能解决问题。

上述问题#1和问题#2，此终无法解决。后面没办法，把IAR版本改为7.3版本，上述问题全部不存在，暂时可以正常使用了。