STM32 Nucleo & Discovery w CubeMX Issues

troneeee · ‎2017-02-04

Posted on February 05, 2017 at 08:08

Subject: STM32 Nucleo & Discovery w CubeMX Issues

02-04-2017

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

and

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->

ADC

COMP

GPIO

LCD

RCC

RTC

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

stm32l1xx_it.c.

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:

GPIO

HAL

PWR

TIM

UART

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 */

etc

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

STM problem?

Thanks in advance,

armor

gps engineer