I am using KSDK 1.2 on a TWR-K64F120M.
I am having a strange issue with mmcau_aes_set_key. When I store my key at certain program flash addresses the processor faults at mmcau_aes_functions.s line 104:
stmia r2!, {r1,r3,r8-r9}
I haven't been able to find any kind of pattern, but so far these addresses work:
0005f32c
0005f354
And these do not:
0005f34c
0005f374
I can copy the key to an array in SRAM to work around this, but I just wanted to understand the root cause of this issue. Is there a limitation to where we can store the key in memory? Does the memory need to be aligned in a certain way? The header file defines the key as const, so i don't expect the read only nature of program flash to be an issue. Something is going wrong though.
Thanks
Solved! Go to Solution.
It appears that the buffer passed in to mmcau_aes_set_key for the key schedule output MUST have an address that is 4 byte aligned. Adding __attribute__ ((aligned (4))) to my array definition solved my problem.
The mmcau documentation states something that hints at this, but does not specify it as a requirement:
For best performance, input and output data blocks must be aligned on 0‐modulo‐4 byte addresses
This is funny actually, because I tested the encrypt/decrypt calls with unaligned memory addresses and there is no issue (aside from maybe slower performance). The only call that has a problem is mmcau_aes_set_key.
It appears that the buffer passed in to mmcau_aes_set_key for the key schedule output MUST have an address that is 4 byte aligned. Adding __attribute__ ((aligned (4))) to my array definition solved my problem.
The mmcau documentation states something that hints at this, but does not specify it as a requirement:
For best performance, input and output data blocks must be aligned on 0‐modulo‐4 byte addresses
This is funny actually, because I tested the encrypt/decrypt calls with unaligned memory addresses and there is no issue (aside from maybe slower performance). The only call that has a problem is mmcau_aes_set_key.
Ok, I was mistaken about this. The key in flash is not the issue. The problem relates to the memory location of the output keyschedule.
Good address: 1fff58e8
Bad Address: 1fff60ce
In this case, the bad address is divisible by 2, but not 4 or 8. The good address is divisible by 2, 4, and 8. Is there just an undocumented memory alignment requirement?