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
已解决! 转到解答。
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?