CC1310: Different behavior between release and debug executables

Hi Ter,

I've just asked a question if anyone had this problem on CC1310. I saw one guy had similar issue on omapl138, see [https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/237127].

I can describe the problem to you:

- the controller is ignoring one specific UART message from PC:

D392 82 12 00000000 23 00 00000000 0000 0000 004d00204d6d0000fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc90110fdc901103bca011079040021dd040021fd040021270500215d05002165040021f8b51047f8b50e4600210125ad04304770b50449084770b503490847f8b5034908470000c94b0000694a0000 C8E0

- this message is including 128 bytes of firmware data

- the software has to receive the message, validate(at the end there is 2 bytes CRC), get the 128bytes from message and store them into the flash

- all other UART message are process correctly

- for UART I'm using TI driver:

#include <ti/drivers/UART.h>

- for writing into flash I'm using driverlib:

#include "driverlib/flash.h"

Now one this things are failing:

- receive message

- validate message

- get 128 bytes

- write 128 bytes into the flash memory

All these tasks are successful only when the optimization level is off.

If you like I can provide you with the output files.

Regards,

Milorad

So I've investigated the problem in more details.

Looks like the compiler doesn't handle well local variables with special type. The type is the following:

typedef union
{
  uint16_t u16;
  struct
  {
    uint8_t byte_0;
    uint8_t byte_1;
  }u8;
}systemword_t;

I've captured on the debugger the issue: 

[]

flashPktIdx is declared locally and its located in R7. flashPacketIndex has then same type but is located in RAM.

You can see that both of them are 0, from debugger point of view. But the software has entered into the if TRUE branch which means that flashPktIdx.u16 != flashPacketIndex.u16

I've checked the value of R7 and R0 (R0 has the value of flashPktIdx.u16). You can see that they are different:

[]

The compiler is writing properly the 16-bit value of 0 into R7 but unfortunately is doing 32-bit comparison and it is letting a random value on the 2 high bytes of the R7:

[]

That's why the software is behaving differently.

If I forced the flashPktIdx to be placed in RAM (declared as static) everythink it would be fine.

Why the compiler doesn't generated proper asm code?

Is this special type the reason?

I've used this type elsewhere in code and I do not have any problems.

Does TI compiler has similar issues?

I would like to have a response on this one because if the compiler had other problems like this I would deactivate permanently any optimization.

Regards,

Milorad

The detailed analysis of the problem looks correct.  I'd appreciate you would send in a test case which allows me to generate the same problem assembly output.  I don't need the entire project.  Please send in the preprocessed form of the source file with the problem if statement.  Also show the compiler (not CCS) version and the build options exactly as the compiler sees them.

Thanks and regards,

-George

Hi George,

I hope you'll appreciate this because it wasn't easy to create this piece of code. It took me few hours to pull it.

I think TI should give me a .. medal or something... :)

So I've just created a CCS empty project(with main.c):

- target: CC1310F128

- compiler version: TI v5.2.7

- optimization level: 0 Register Optimizations

- Build configuration: debug

Files:

[[View:/cfs-file/__key/communityserver-discussions-components-files/81/2402.main.c:1230:0]]

[[View:/cfs-file/__key/communityserver-discussions-components-files/81/main.pp.txt:1230:0]]

Now, I don't have to tell you that you need to change the linker file in order to compiler successfully the project:

/* Retain interrupt vector table variable                                    */
--retain=g_pfnVectors
/* Override default entry point.                                             */
//--entry_point ResetISR
/* Allow main() to take args                                                 */
--args 0x8
/* Suppress warnings and errors:                                             */
/* - 10063: Warning about entry point not being _c_int00                     */
/* - 16011, 16012: 8-byte alignment errors. Observed when linking in object  */ 
/*   files compiled using Keil (ARM compiler)                                */
--diag_suppress=10063,16011,16012

I think I don't need to explain what I've done in the code but if you need clarification please let me know.

.. and I still need some answers..

The compiler has similar issues? Or you suggest to let the optimization off?

Regards,

Milorad

Thank you for the test case.  I can reproduce the problem.  I filed SDSCM00052864 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

Milorad Podoaba said:

I hope you'll appreciate this because it wasn't easy to create this piece of code. It took me few hours to pull it.

I'm sorry about that.  I try to make my directions clear.  You only needed to preprocess the source file with the problem comparison.  That creates a .pp file.  You have to add the extension .txt to the .pp file in order to have the forum accept it as an attachment.  Then tell me the compiler version, and show all the build options.  That's it.  I don't need to run the code.  In fact, I seldom have the hardware needed to run it.  Because that is usually the case, I long ago found techniques for debugging problems that do not require running the code.

Thanks and regards,

-George