STM32F215 : Issue to start up the crypto processor peripheral

[tlamotte9]

Posted on March 25, 2014 at 18:00

Dear All,

I run into troubles when I try to start up the crypto processor of my STM32F215. After the line 1, the cryptoprocessor peripheral does not start up: line 1: RCC_AHB2PeriphClockCmd(RCC_AHB2Periph_CRYP, ENABLE); line 2: CRYP_AES_ECB(MODE_ENCRYPT, (uint8_t*)AESKey, 128, CryptBufferIn, CRYPTBLOCKSIZE, CryptBufferOut); It is worth mentioning that I use our own hardware (STM32F215) that has an external 10MHz quartz. AHB2, APB1 and APB2 are all driven by the same frequency : 10MHz. We normally do not use the PLL. I even tried with a AHB2 much higher than 10MHz, it still does not start either. Now, if I use the same 2 lines code on the Eval Board STM3221G-EVAL (STM32F217), it works well. After investigation, the only difference I have seen between both hardware is the external quartz that is not 10MHz but 25MHz and the AHB2=120MHz Please, I would like to know if there is any minimum frequency from the external quartz to make the crypto processor work? I went through the STM32F2xx reference manual and datasheet but both do not mention anything regarding this issue. Any help would be welcome. Best regards, Thierry

[Tesla DeLorean]

Posted on March 25, 2014 at 18:15

If it's anything like the SDIO peripheral, you NEED the PLL running to get ~48 MHz clock off the Q Tap of the PLL. This goes also to the RNG / HASH also.

[tlamotte9]

Posted on March 26, 2014 at 08:06

Thanks Clive for your answer.

Before posting my question, I already made this try. It works well for the RNG (that we punctually use in our application) but it does not work for the crypto processor. No way to start it. This morning by doubt I made another try: - On our own hardware I changed the external quartz from 10MHz to 25Mhz - I re-used the system_stm32f2xx.c I use in the Example of the STM3221G-EVAL where the crypto processor normally starts - I double-checked the clocks invoking RCC_GetClocksFreq(&RCC_ClocksStatus); before running RCC_AHB2PeriphClockCmd(RCC_AHB2Periph_CRYP, ENABLE); all them seems ok Unfortunatelly, the crypto processor still does not start. Any help would be appreciated, Best regards, Thierry

[Nickname12657_O]

Posted on March 27, 2014 at 21:48

Dear Thierry,

Please be in touch with  your Local ST representative or distributor  linked to your Company account to get the full answer for your case. you need to send us back that device  STM32F215 not containing the HW crypto engine and our sales will replace it for you for free.  I  know that you already contacted us via  our web tool, you will be served. Cheers, {STOne-32}

[Tesla DeLorean]

Posted on March 28, 2014 at 03:36

RCC->AHB2ENR |= RCC_AHB2ENR_CRYPEN;
if (RCC->AHB2ENR & RCC_AHB2ENR_CRYPEN)
puts(''CRYP Unit PRESENT'');
else
puts(''CRYP Unit ABSENT'');

[tlamotte9]

Posted on March 28, 2014 at 13:10 I warmly thank both of you for your answer. I just did the test you advise me: the outcome is : ''CRYP Unit PRESENT'' (see attached snapshot) Since my post and my online support request (as you mentioned it), I have kept on investigating. Here is a breve summary: - I contacted our ST distributor: they are not able to us, they get in touch with ST... - It is worth mentioning that, before designing our own hardware, we used a few ST Eval boards but mostly the STM3221G-EVAL board that embeds the STMF32F217 (close to our own soc, the STM32F215). > I did a complete memory dump of the Eval Board (let's call it ''image''). The purpose was to avoid any difference of memory content I could not be aware of. > I wrote a minimal project that just call SystemInit() and right after it does the RCC->AHB2ENR |= RCC_AHB2ENR_CRYPEN; Then I did the following procedure on the 2 boards : the STM3221-EVAL and our own board. (1) I download the memory image (2) I download my minimal project (3) run it and look after the enable of the crypto processor whether or not it is activated Outcome: On the STM3221-EVAL, it starts. On our own board, it does not. Meanwhile the code is STRICTLY the same. For note, I took care about hardware equivalence for this test concerning the external quartz: both hw had a 25MHz crystal. The only major difference I noted is that ''not each power supply pair of our soc is decoupled with one filtering ceramic capacitor'' (some are not) as mentioned in the STM32F2xx datasheet i.e. our hardware designer did not strictly followed the ST recommendations regarding the power supply scheme. Soc is clocked at 10Mhz and he might think it was enough. Does this weak decoupling could lead us to stall the crypto processor when we enable it? Besides this, our investigations lead us to think that some prerequisite activation of the crypto-processor exists, might be non-documented for some obvious export raison, etc. Maybe we are wrong but since we do not have more support.. For now, we are waiting for the response of our local distributor. Hope their anwser will come asap. Best regards, Thierry Lamotte ________________ Attachments : outcome.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0pR&d=%2Fa%2F0X0000000beD%2F4xyQShbmvroZfB920cL7nUgibr5RweutTEKPEIH8sMY&asPdf=false

[Tesla DeLorean]

Posted on March 28, 2014 at 18:28

My boards typically use a 205 running off at 120 MHz off a 16 MHz HSE crystal. I have built a number using the STM32F215ZGT6 parts we sampled from ST. I did a quick test this morning running directly from the 16 MHz, with the AHB/APB1/APB2 running at 16 MHz also, and no PLL running.

I used the some standard library code to do an AES-128 encrypt and decrypt test and got back my original data. It was not particularly thorough, but probably sufficient to exercise the engine. If you'd like to discuss privately, off forum, my email is sourcer32@gmail.com

[Nickname12657_O]

Posted on March 28, 2014 at 19:21

Dear Thierry,

As I said,  Please proceed by returning back that device to your distributor our STMicro nearest sales  office, they will change it for free.  we have shipped some early devices without HW crypto engine despite the fact they are either  STM32F217  or STM32F215 from our factories and are proceeding by an RMA.  Cheers, {STOne-32}

[tlamotte9]

Posted on March 31, 2014 at 08:50

Dear STOne-32,

From our point of view, we are not talking here about one single micro to be replaced but many of them that are all already solded on board meanwhile the project is getting late. Best regards, Thierry