CAU (cryptographic acceleration unit) for MCF51JM128RM

[CamiloA_]

Hi how are you? I would appreciete some help regarding the implementation of the AES functions. I`m using Codewarrior 6.2. I know this in an old IDE but I`m working on an old project which I`m modifying and improving. I have a couple of questions and problems. I already did what I`ve found in the manuals and it seems to be ok, no errors in compilation. But when I want to invoke the first function (cau_aes_set_key), the program gets lost and does nothing. I don`t know why and I find something that I consider strange, this function doesn´t turn "blue" like all other pre-defined functions, I don´t know if this is normal or an indicator of problems. However it seems that the compilator actually recognizes this function, because if I misspelled it,Compilator will show some errors. Thank you in advance for your cohoperation.

Warm regards.

[erabhinandan]

#if FREESCALE_CAU TRUE

__declspec (standard_abi) 
i have added above lines in the header file but it is giving error for __declspec where i am using tool chain for MFC5485 coldfire.
Can you explain how i compile the with __declspec without error.

[erabhinandan]

Dear Sir,

I am using cryptolibrary and compiling the code on linux platform with m68-linux-gcc- toolchain.I have intergrated the libcau.a library.but when i used the 

asm void __declspec(compact_abi) check_CC(unsigned long)
{
....
} 

__declspec is not supported by gcc on linux.Can you sugest me how i can manage (inplace of __declspec to use other option) to resolve the problem.

[TomE]

I misread your question as it didn't say (until you send a clarification) that you were using Linux.

You don't need that "declspec" for gcc. That's a CodeWarrior thing to do with their calling conventions. Linux has ONE calling convention, so you don't have to worry about this.

What you DO need to worry about is calling machine-language functions. It looks like the CAU library has to read the condition codes. It looks like they provide an assembly-in-C function to do that. Had you provided the ENTIRE function rather than deleting the middle I could see what it does and advice what to do.

I note that previous (2012) answers in this thread say that the "library" is in Assembly. You won't be able to compile that if that's true.

Could you also post a link to the source of the library so I can see what it does and so what you are trying to do? Here's someone in 2011 looking for it (and not finding it):

https://community.nxp.com/t5/CodeWarrior-for-QorIQ/ColdFire-CAU-Software-Library/m-p/193501

Is it this one?

https://www.nxp.com/design/development-boards/tower-development-boards/mcu-and-processor-modules/kin...

The "README.txt" file in there says:

Assembly Language Format and Porting Considerations

These functions are written in the ColdFire assembler used by the Core &
Platform design team. This assembler may not be compatible with the wide
assortment of other development tools, but typically can be easily translated
into the required format.

It then gives some warnings. You have to be careful with the "cmp" instructions. Different assemblers have the source and destination in the opposite order.

But there's no "check_CC()" function in there, so I don't think that's the library you're using. The only place I can find that function is in TN270:

https://www.nxp.com/docs/en/application-note/TN270.pdf

As for that "check_CC()" function, the gcc compiler library (or other headers) may already supply an equivalent function that you should call instead. Otherwise you have to write an equivalent assembly function (if it is reading the CAU conditions, which I doubt) and make sure that obeys gcc's function calling convention for register usage and parameter passing.

In case anyone is searching for problems about running old example code on new versions of Codewarrior (and searches for keywords), I'll leave the following for reference:

This is a really OLD problem.

When CodeWarrior went from Version 7.1 to 7.2 (back in 2010, THAT long ago) they changed from supporting (standard_abi) to only supporting (register_abi). Read TN268 for details on this.

https://www.nxp.com/docs/en/application-note/TN268.pdf

With (standard_abi) aka "STD_ABI" the convention is to pass all parameters to functions on the stack. With (register_abi) it passes as many parameters as it can in registers. This makes the generated code smaller and faster. The problem is that ALL CODE (your code and all the compiler and system libraries) have to agree on this. It probably got too hard for them to support both, so 12 years ago they dropped support for the old way.

From my notes on this subject:

Search (at top right of this page) for "REG_ABI".

Other posts said that prior to 7.2 you could select either option, and all the libraries and example code on Freescale's web site defaulted to STD_ABI. With CW7.2 that option was removed, and it changed to REG_ABI. So all existing Assembly code broke, and none of the sample code (in App Notes and so on) got updated. This traps everybody, but isn't documented anywhere that I can find. It might be in the documentation provided with CW somewhere, I've never had a copy to check.

7.12 was released in June 2nd, 2009.

7.2 released 22 Jan 2010.

That also means that all the huge amount of example code for all their processors and modules STOPPED WORKING (or at least meant you couldn't compile and use it any more). They didn't convert and re-release this code to work "the new way", so it means that anyone wanting to use the old libraries has to learn everything about the CPU, the compiler, register conventions (become a literal super-expert) and do the conversion themselves.

Either that or use CodeWarrior 7.1 (or whatever was the last version to support the old code). You can't buy an old version, so if nobody kept a copy from.

Here's a post from me in 2013 about this:

https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Privilege-Violation-Exception/m-p/280548

Another from (like I said) 2010:

https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Problem-in-trying-to-get-MCF52233-DEMO-BO...

Tom

[PaoloRenzo]

Hi Camilo

CAU library is delivered in assembler. A header file works as the link between the library and the application. I would think functions being not blue could be a problem but instead try to debug in assembler the calling function to understand if the parameters are correctly sent by the compiler as the library expects them. Is your project set up for standard parameter passing (stack) instead of register parameter passing?

Also, try adding this special declaration before each CAU prototype:

__declspec (standard_abi)

I would look into the following guide even if it's an old compiler:

http://cache.freescale.com/files/32bit/doc/user_guide/CAUAPIUG.pdf

Hope this helps

[lumi]

I have the exact same problem as Camilo Camacho. Using MCF51JM128 and the CAU library. I read Paolo's AN4307 (+AN4234). I added "#define FREESCALE_CAU (1)" and verified in the dissasembly that the parameter passing is actually working. Debugging step by step I get to an illegal opcode exception after branching to deal with AES128.

Setup:

Windows 7. CW 10.1 for MCU, Build Id:110204. No MQX. CAU Library 2.3. MCF51JM128.

Help will be appreciated!

[PaoloRenzo]

Hi

More input is needed here. Are you able to execute other crypto functions? cau_aes_set_key?

Regards

Paolo

[lumi]

Paolo,

No, I can't execute any function of the library related to AES. However, we just found the root cause of the problem: the microcontroller version that I am using does not include a CAU co-processor. The MCF51JM128 datasheet states that there are different part numbers for the modules that include a CAU and the ones that doesn't. For example: MCF51JM128EVLH vs MCF51JM128VLH I was not aware of that difference. Thanks anyway.

[PaoloRenzo]

Hi Lumi

We found that using CAU over a crypto software implementation while running AES128 in the MCF52259@80MHz improves performance ~2.7 times. I don't have that info for the V1 core, but this should give you an idea.

Hope this helps

Paolo

[JimDon]

Assembler? All I see are binary lib files (.a) (in CAU_MMCAU_SW.zip)

Is the source available?

[PaoloRenzo]

I'm sorry. My last answer was not clear. If you debug the library you should be able to see the assembler code.

Source files are NOT available.

[JimDon]

Just as much my mis-understanding, though I suppose "delevered in binary" is more correct.

Well, if you define  FREESCALE_CAU, then __declspec (standard_abi) will be added in the .h files.

#if FREESCALE_CAU__declspec (standard_abi)#endifvoid cau_aes_set_key (const unsigned char *key, const int key_size,                       unsigned char *key_sch);