AnsweredAssumed Answered

STM32 Nucleo & Discovery w CubeMX Issues

Question asked by Knee_Ph.D..Trahn on Feb 5, 2017

Subject: STM32 Nucleo & Discovery w CubeMX Issues


Hi there all, I am experiencing both compile and execute problems.

Any help is appreciated.


Compiler: Rowley CrossWorks v3.65.2016061400.28363 (hah hah hah)
CubeMX F4 V1.14.0
CubeMX L1 V1.6.0
STM Test Boards:


 - STM32L152C-Discovery (has a six digit 14 seg LCD on it)
 - Nucleo-F401RE (really kewl morpho connectors, very useful...too bad nothing works)


Two different types of CubeMX were installed, one for STM32L15x and the other for STM32F40x.

Both were installed under their respective lib types:


under 'repository->STM32CubeMX_FW_L1_V1.6.0->Projects->Examples->


Of the above examples, only the 'LCD segment drive' demo successfully compiles and executes properly.
All the other examples fail to execute properly. I can not find the problem. All of the other L152C 'demo'
example programs, compile, but when they execute, they fail into the 'Hard-Fault' handler, yet all
are configured (at least in the code) the same for all example programs for the L152-Discovery
board. For instance, the GPIO example, imported using the Keil import function of the Rowley Crossworks,
IDE/Compiler tool chain, compiles. I download the code into the Disco-L152C board via the embedded
ST-Link V2 debugger USB-interface.  


I execute single-step, step-over (F10) function, to hop over Main(),
down to HAL_INIT();
then single-step-into SystemClock_Config();
which calls the subroutine that configures the RCC clock structure RCC_ClkInitStruct
and then (I re-arranged for clarity & debug) executes:


uint8 rcc_rtn_flg;


rcc_rtn_flg = HAL_RCC_OscConfig(&RCC_OscInitStruct); // does not return from here


if (rcc_rtn_flg != HAL_OK) {
   while(forever);  // program never gets here as it becomes trapped in hard-fault handler


The call to HAL_RCC_OscConfig vectors to:


HAL_StatusTypeDef  HAL_RCC_OscConfig(RCC_OscInitTypeDef *RCC_OscInitStruct)
   uint32_t tickstart = 0U;


It executes to the tickstart = 0U; statement and next single-step vectors into HardFault_Handler in module


It would have been informative for the programmers to have included a stack dump in some manner
in the handler instead, for us beginners.  I suspect that the problem is being caused by a compiler
setting of some sort, eg, a missing DEFINE or something similar, hidden in the obfuscation of the RCW 'project'
settings. Make file versions are best, one can figure out what may be missing.


Of the CubeMX F4 examples:


None of the above successfully compile. All fail in module, core_cm4.h emitting four errors, there
could be other errors also. I suspect it is a (hidden) RCW setting, but with these disjointed tools
and libs, it could be anything. While the error messages emitted might as well as being
alien language from zeta reticuli, in my opinion.


ERROR: expected '{' before 'volatile'
line: 275
#define __IM volatile const   /*! Defines 'read only' structure member permissions */


Anybody else having these problems? Should I be yakking at Rowley Crossworks or is this an
STM problem?


Thanks in advance,


gps engineer