Which were later typecast to (uint8_t *) and accessed with offsets. This meant that it assumed an 8-bit device was used, as on the 32-bit device it would align the 8 bit variables to 32-bit address boundaries. This allowed faster access on the 32-bit machine.

Solved the problem by forcing hte compiler to pack everything together by adding __attribute__ ((packed)) after each variable declaration.

The strange thing is that that code has never been modified and not the structure opt neither.

Furthermore the problem happens on the second call of the function, here are the values of R7 and R9:

1st call, works

R7 0x0000FFB8

R9 0x00000004

2nd call, EXCEPTION RAISED

R7 0x000000F7

R9 0x00000004

Adding packed attribute to the structure opt doesn't work, The problem happens randomly when I do other modification to other part of the code that shouldn't be related to this struct. I tried to revert back to see the disassembly of the same C code and the problem doesn't happen because ld.sh R9, R7[6] is not generated.

Certainly in ARM this is almost always the reason for a data exception. I assume that is the same here for UC3 ? So is it an alignment thing? I guess the implication then is that R7 holds an odd number.

EDIT: should have read more closely - so, yes F7 *is* an odd number - so this is expected. I guess the real fault is "what is R7 doing holding an odd number at this point?"