This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SIMPLELINK-CC13XX-CC26XX-SDK: HardFault caused by misaligned pointer in bdb_reporting.c

Other Parts Discussed in Thread: CC2652RB, Z-STACK

With SimpleLink CC13XX/CC26XX SDK Version, attribute reporting for float (ZCL_DATATYPE_SINGLE_PREC) attributes fails with a HardFault due to a misaligned pointer access on line 1895 in bdb_reporting.c:

      float L = *((float*)lastValue);
      float D = *((float*)delta);
      float C = *((float*)curValue);

With -O0 this works, but with -Oz the FPU instruction loading the (misaligned) float causes a HardFault.

The pointers lastValue, delta, and curValue are of type uint8_t*, and at least lastValue and curValue are not properly aligned (address divisible by 4) for a float pointer. Dereferencing misaligned pointers causes undefined behaviour in C, so a HardFault is a perfectly valid result here.

The same thing probably happens for other attribute types with _Alignof larger than 2, but I haven't tested that.

I worked around the issue by using a defensive memcpy for all three values:

      uint8_t len = zclGetDataTypeLength( datatype );
      float L, D, C;
      OsalPort_memcpy( &L, lastValue, len );
      OsalPort_memcpy( &D, delta, len );
      OsalPort_memcpy( &C, curValue, len );

That should probably be fixed in the SDK.

  • Please provide info on which example from the SDK you are using.


  • I am using the zr_temperaturesensor example on CC2652RB, extended with one of the Concentration Measurement (CONC) Clusters - specifically the one for carbon dioxide (Cluster ID 0x040d).

    All CONC clusters (IDs 0x040c to 0x042b) have a reportable attribute "MeasuredValue" of type "single". Outside that cluster range, floating point values are rarely used in the ZCL, and I didn't find any other instance of a reportable attribute of type "single" in the ZCL spec (R7 and R8).

    The zr_temperaturesensor example works fine out of the box. With the additional attribute, it also works fine as long as I don't configure reporting for the attribute. With the above memcpy workaround, it also works fine with reporting.

    I'm assuming reporting works for integer types, because the Arm Cortex-M4 CPU can handle misaligned load/store instructions, while the FPU does not. But even for integers, dereferencing misaligned pointers causes undefined behaviour in C, so the current implementation is not portable.

  • Hi Christian,

    Thank you for providing your feedback, reporting this issue, and supplying a viable workaround towards the SimpleLink F2 SDK Z-Stack solution.  This nuance was likely missed during TI's annual stack testing since it does not proliferate on the existing default examples.  Nevertheless, I have notified the Software Development Team of this issue and filed a bug ticket so that it may be addressed in a future SDK release.


  • Hi Ryan,

    thank you and Siri for your quick response and action.