STM32F4 Unknown CFSR register constents problem

[hermanv]

Posted on November 05, 2013 at 14:31

Hi all,

I am porting code from an existing Intel 8031 platform onto a STM32F4 The software performs PID calculations. The softwqare has been running without issues on the 8031 for several years, but I am having difficulty getting it to work on the STM32F4. A hardfault failure occurs as soon as I the contents of a structure is compared/used. The hardfault errors as printed out via debug messages are:

SCB_HFSR:40000000<
CR
><
LF
>
SCB_CFSR:01000000<
CR
><
LF
>

According to the Cortex-M4 programming manual, the bit set in CFSR is supposed to be reserved, thus I do not know what it means if bit 28 is set. All I know it that it is a user fault. Here is the structure containing the data for PID calculations:

#pragma pack(push,1)
typedef struct
{
int auto_man;
int forward_rev_ctrl_flag;
int output_inc_dec_flag;
int pid_init;
int auto_man_last;
double *var_x;
double *var_x_low_end;
double *var_x_high_end;
double *setpoint;
double *prop_gain;
double *int_time;
double *diff_time;
double *output_y_man;
double integral_pre;
double differential_pre;
double prop_term;
double int_term;
double diff_term;
double range;
double xw;
double xw_old;
double xw_sum;
double output_y;
double output_y_temp;
}PidStruct;
#pragma pack(pop)

Here is the declaration of the structure:

static PidStruct pid[2];

Here is the usage of the code. Failure occurs at line 33

double pid_compute( int arr,

int auto_man,

int forward_rev_ctrl_flag,

int output_inc_dec_flag,

int pid_init,

double far *var_x,

double far *var_x_low_end,

double far *var_x_high_end,

double far *setpoint,

double far *prop_gain,

double far *int_time,

double far *diff_time,

double far *output_y_man

)

{ 

int x;


x = arr-1;

if(pid_init == 1)

{

pid[x].var_x = var_x;

pid[x].var_x_low_end = var_x_low_end;

pid[x].var_x_high_end = var_x_high_end;

pid[x].setpoint = setpoint;

pid[x].prop_gain = prop_gain;

pid[x].int_time = int_time;

pid[x].diff_time = diff_time;

pid[x].output_y_man = output_y_man;

pid[x].forward_rev_ctrl_flag = forward_rev_ctrl_flag;

pid[x].output_inc_dec_flag = output_inc_dec_flag;


/* precalculations for pid algorithm */

if(*pid[x].int_time == 0.0)

{

Any ideas what might be wrong? Thanks, H #stm32f4 #cfsr #stm32f4 #hardfault

[Tesla DeLorean]

Posted on November 05, 2013 at 14:47

I do not know what it means if bit 28 is set.

Isn't bit 24 UNALIGNED?

[hermanv]

Posted on November 05, 2013 at 14:53

Hi Clive,

You are right, that is bit 24. My mistake.I did pack the structure bytewise in an attempt to cancel out any alignment issues, but this had no effect.Any suggestions?Thanks,H

[Tesla DeLorean]

Posted on November 05, 2013 at 15:05

I don't have a clear view of this. Most of the structure seems to have 4 or 8 byte alignment, so not clear on the need for 1-byte packing. Does it fault without the packing?

You might want to dig into which specific instructions are choking, and which structure elements are problematic. I'd probably want to validate the array index too.

[hermanv]

Posted on November 05, 2013 at 15:23

Thanks Clive,

With of without byte packing it still fails.I will follow your advise and try to isolate the item giving problems. Although the array index is valid, I will add validation for safety sake.Will post again if I found the solution or need more help.Thanks

[waclawek.jan]

Posted on November 05, 2013 at 22:37

What is the value of

pid[x].int_time 

(i.e. the pointer)? JW

[hermanv]

Posted on November 06, 2013 at 07:14

The pointer points to address 0x10000271 and the contents of that address is 10.0.

Some of the data passed to the function is located in the CCM memory area. I am going to investigate today whether this might be the cause of the problem.H

[waclawek.jan]

Posted on November 06, 2013 at 09:56

> The pointer points to address 0x10000271

Okay, so isn't that the unaligned address the attempted to access? From Cortex-M4 TRM, 3.4.2: ''Unaligned support is only available for load/store singles (LDR, LDRH, STR, STRH).  Load/store double already supports word aligned accesses, but does not permit other unaligned accesses, and generates a fault if this is attempted.'' Have a look at the disassembly at the point of failure, what instruction is there. Try to align the pointer target. JW

[hermanv]

Posted on November 08, 2013 at 09:36

Thanks for all the advice.

I packed some structures bytewise in order to save space when storing the structure data to FLASH memory as part of configuration information. This caused all the unaligned access issues. I updated the code to handle the space saving to FLASH differently to allow the structures to be be used word-aligned. All is well again.H