KE02Z64 project with ARM Compiler -Os Size Optimization flag cause CPU reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KE02Z64 project with ARM Compiler -Os Size Optimization flag cause CPU reset

Jump to solution
856 Views
sys
Contributor III

Hi all,

we are having problem with a MKE02Z64VLH4 project.

We are compiling the project using the "Cross ARM GCC" Toolchain (arm-none-eabi-gcc). For code-size matter, we need to use the "-Os" compilation flag, which means the compiler will compile with Optimization level set to "Optimize size". IDE is KDS 3.1.0.

With this settings, everything looks ok, except for this function:

uint8_t CheckCode(uint8_t *Code) {
     if (*((uint32_t*)(Code)) == epmID) {
          return 1;
     }
     return 0;
}

when this function is called, che CPU hangs, resetting itself. After some analysis with step-by-step debug, we found that the problem is in the equal comparison. We found 2 solutions, one is this:

uint8_t CheckCode(uint8_t *Code) {
     uint32_t Cod;
     Cod = *((uint32_t*)(Code));
     Cod |= ((*(Code + 1)) << 8);
     Cod |= ((*(Code + 2)) << 16);
     Cod |= ((*(Code + 3)) << 24);
     if (Cod == epmID) {
          return 1;
     }
     return 0;
}

As you can see, using a support variable (local), everything is fine now.

Another way is to replace the function calling directly with the equal comparison:

//... some code
if (albCmdRx1 == BTC_CONNECT) {
    if (!epmfCANCONNECT) {
     Error(ERR_CONN_DISABLED);o
//    } else if (CheckCode(albParamsRx1)) { // THIS CAUSE THE CPU RESET
      } else if ((*((uint32_t*)albParamsRx1)) == epmID) { // THIS *DONT* CAUSE THE CPU RESET

//... some other code

The calling function is use directly in the main.c file. "albParamsRx1" is an array of uint8_t.

It seems is a problem with *(uint32_t*) cast in the if comparison mixed with the fact that there is a function calling.

We would like to know if this is a known problem, how it works exactly and how to be sure that there is no other point in code that can cause the problem, considering that there is no warnings or compiling errors. We resize the stack size, without luck.

We think it's a problem similar to this one , but there is no real solution or reason that explain the problem.

Thanks in advance for help,

Sandro

Labels (1)
Tags (3)
1 Solution
648 Views
bobpaddock
Senior Contributor III

-Os may generate code that does not align things on native 32 bit boundaries leading to bus faults.

Look at the addresses of the pointers, variables, the array itself etc. in question.  Are they aligned on 32 bit boundaries?

Align the array on a 32 bit boundary to see if that fixes it, syntax for GCC:

static uint8_t array_u8[ 256U ] __attribute__((__aligned__(4U)));

Do you have a hard fault monitor/IRQ enabled (doesn't sound like it)?

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/ 

View solution in original post

3 Replies
648 Views
bobpaddock
Senior Contributor III

An other, less likely cause, of issues with -Os is that something needs be marked 'volatile' that isn't.

0 Kudos
649 Views
bobpaddock
Senior Contributor III

-Os may generate code that does not align things on native 32 bit boundaries leading to bus faults.

Look at the addresses of the pointers, variables, the array itself etc. in question.  Are they aligned on 32 bit boundaries?

Align the array on a 32 bit boundary to see if that fixes it, syntax for GCC:

static uint8_t array_u8[ 256U ] __attribute__((__aligned__(4U)));

Do you have a hard fault monitor/IRQ enabled (doesn't sound like it)?

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/ 

648 Views
sys
Contributor III

Thanks a lot Bob!

The problem was exactly the alignment, adding the attribute resolved the problem.

Anyway we proceed with the first solution, so we dont need to care about alignment.

We needed anyway to understand the problem, thanks again for the help!

Sandro

PS: Thanks for the IRQ stuff link, it is useful.