HardFaults when trying to convert data on ARM

0

I'm trying to perform conversions of some data that I'll use to perform calculations. I'm using an ARM Cortex M4 and code is written in C.

Here's covertions and calculation I'm going to make:

//First Calculation
//This are inside a function:
volatile float new_freq_temp;
volatile int new_data_qty;

uint32_t new_freq = (int) ((500/new_freq_temp)/new_data_qty);

//Second Calculation
//This are globals:
static volatile uint32_t monitor_freq = 0;
static volatile uint32_t monitor_data_qty = 0;

float tot_freq = (float) ((500.0/ ((float) monitor_freq))/((float) monitor_data_qty));
uint8_t *array_data_p;
array_data_p = (uint8_t*)(&tot_freq);

The two calculation are each one in a separate functions and are not related, but they are very similar.

From when I've added this two calculation I've started to encounter some random HardFault. I've performed some test and with this last configurations(that I've post above) seems that all works, but I'm worried about if I perform in correct way this operations. Also, since this HardFaults wasn't frequent, I need to be sure that this operations are reliable in long time.

In particular, in test I've done, I've found this strange things:

  • If I add in First Calculation a point to 500 like this ((500.0/new_freq_temp)/new_data_qty) this causes HF, when if I add same thing to Second Calculation this doesn't happen.
  • If I remove from (float) ((500.0/ ((float) monitor_freq))/((float) monitor_data_qty)) point zero from 500 OR remove redundaunt (float) that wrap all operation it causes random but not frequent HF.
  • If add Volatile to result variable like volatile uint32_t new_freq or volatile float tot_freq this causes a HF

I premise that I should use this type of variables and I can't change all to float.

This convertions are correct or how I can make them better to avoid HardFaults?

p.s. This are HardFaults that I've registred:

stacked_r0  0x00409435      stacked_r0  0x20000d0c      stacked_r0  0x00409435

stacked_r1  0x00000005      stacked_r1  0x00400e79      stacked_r1  0x00000005

stacked_r2  0x00401561      stacked_r2  0x0040a141      stacked_r2  0x00401561

stacked_r3  0x20000924      stacked_r3  0x00000200      stacked_r3  0x20000924

stacked_r12 0x0040146d      stacked_r12 0x20000d50      stacked_r12 0x0040146d

stacked_lr  0x00000001      stacked_lr  0x20000d0c      stacked_lr  0x00000001

stacked_pc  0xa000005d      stacked_pc  0x20000d08      stacked_pc  0x0000005d

stacked_psr 0x00000005      stacked_psr 0x20000924      stacked_psr 0x00000005

_CFSR   0x20000924      _CFSR   0x00000000      _CFSR   0x20000924

_HFSR   0x00000000      _HFSR   0x20000dcc      _HFSR   0x00000000

_DFSR   0x00000000      _DFSR   0xa8401601      _DFSR   0x00000000

_AFSR   0x3fefde7f      _AFSR   0x200008d5      _AFSR   0x3fef0050

_BFAR   0x0040149b      _BFAR   0x20000000      _BFAR   0x0040149b

_MMAR   0x3f7dc000      _MMAR   0x00000005      _MMAR   0x3f7a0000
c
arm
cortex-m
asked on Stack Overflow May 3, 2016 by Singee

0 Answers

Nobody has answered this question yet.


User contributions licensed under CC BY-SA 3.0