mmcau_aes_set_key problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mmcau_aes_set_key problem

Jump to solution
699 Views
kalden_srcinc
Contributor IV

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

Labels (1)
0 Kudos
1 Solution
553 Views
kalden_srcinc
Contributor IV

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.

View solution in original post

0 Kudos
2 Replies
554 Views
kalden_srcinc
Contributor IV

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.

0 Kudos
553 Views
kalden_srcinc
Contributor IV

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?

0 Kudos