pointer usage for data copies does not work on arm r5

[hauptmech]

There are a few issues. Unfortunately I don't have time to do a patch. Here are a few breadcrumbs if someone else has issues:

src/libecbor/ecbor.c#61

//float //<- after swizzle, we aren't a float anymore. 
uint32_t // hack: struct packet { uint8_t data[4]; } is probably better 
ecbor_fp32_from_big_endian (float value)
....
//return *((float *) base); // <- could be an invalid combination of bits for a float after swizzle, triggering processor exception
return *((uint32_t *) base);

src/libecbor/ecbor_encoder.c#128

  } else {
    /* 8 extra bytes */
    (*context->out_position) =
      ((major_type & 0x7) << 5) | ECBOR_ADDITIONAL_8BYTE;
    context->out_position ++;
    (*((uint64_t *)context->out_position)) = // <- causes data abort exception because uint64 address is not aligned correctly
      ecbor_uint64_to_big_endian ((uint64_t) value);
    context->out_position += 8;
    context->bytes_left -= 9;

My fix ( I don't trust ecbor_memcpy handles address/data alignment correctly and I do have libc)

  } else {
    /* 8 extra bytes */
    (*context->out_position) =
      ((major_type & 0x7) << 5) | ECBOR_ADDITIONAL_8BYTE;
    context->out_position ++;
    uint64_t temp = ecbor_uint64_to_big_endian ((uint64_t) value);
    memcpy(context->out_position, (uint8_t*)&temp, sizeof(temp) );
    context->out_position += 8;
    context->bytes_left -= 9;
  }

[rimio]

Hey, thanks a lot for the report and hints. It would help a lot if you could give some more info about the system being used and maybe some sort of minimal reproduction steps/scenarios so that I start pulling on the thread somewhere.

[hauptmech]

System is Arm 7 (M4F and R5F series). (Texas Instruments AM2434)

I think the key thing is that once you change the endianess, they are no longer the same type. UINTxx is the only type that looks similar to the processor. So for all the endianess changes, you are going from whatever the system type is (int, float, etc) to a sequence of bytes.

A processor hard fault on the invalid combination of bits for a float value is what was my first indication of a problem.