cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Cyptolib with IAR 8.11

Giuseppe Cannarella
Associate II

Posted on April 13, 2017 at 09:11

I've my application that uses the xCube CyptoLib 3.1.0 (STM32CryptographicV3.0.0_CM4_IAR_otnsc.a)with IAR compiler. Up to version 8.10 of the IAR compiler I never had any warning or error during the build of the project. Upgrading the IAR IDE to version 8.11 I have this error:

'Warning[Lt009]: Inconsistent wchar_t size crypto.o(STM32CryptographicV3.0.0_CM4_IAR_otnsc.a) has wchar_t size 16 bits '

Reading the release notes of the IAR 8.11 I found this:

IAR Information Center for ARM

Changed size of wchar_t in version 8.10 and 8.11

Object files following the ARM ABI has a runtime attribute indicating the size of wchar_t.

In EWARM version 7.80 and earlier, the size of wchar_t was 2 bytes wide and the runtime attribute was set accordingly.

For EWARM version 8.10, the size of wchar_t was 4 bytes wide but the value of the runtime attribute was not updated. Thus in 8.10 code is generated with 4 byte wide wchar_t but the object file is marked as if wchar_t is 2 bytes wide.

In EWARM version 8.11 wchar_t is 4 bytes wide and the runtime attribute is set accordingly.

Looking only at the wchar_t aspect this has the following implications:

All good except need to remove all parent title text for all comments.

Need to remove all parent title text for all comments.

  • Combining object files built with 7.80 and 8.10 will not trigger any linker warning but if the application uses wchar_t, the behavior will be unpredictable.
  • Combining object files built with 8.10 and 8.11 will trigger a linker warning but the application should work even if it uses wchar_t.
  • Combining object files built with 7.80 and 8.11 will trigger a linker warning and if the application uses wchar_t, the behavior will be unpredictable.

Then, by this description, theCryptoLib 3.1.0 needs to be rebuilded with new version of the compiler to avoid unpredictable issues.

I planned a new release of the Crytolib compiled with IAR 8.11?

How I can solve this issue?

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Nesrine M_O
Lead II
Posted on June 01, 2018 at 10:18

Hi all 

Sorry for the delay to come back to you!

As committed a new 

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/patchx-cryptolib.license=1527840120231.html

for

http://www.st.com/en/embedded-software/x-cube-cryptolib.html

is now available to support the new IAR version : IAR Embedded workbench for ARM(EWARM) toolchain V8.22.

Thank you very much for your interest on our STM32 products.

-Nesrine-

View solution in original post

19 REPLIES 19
Peter Morrow
Associate II
Posted on April 18, 2017 at 09:14

We are facing the same issue here but with the STemWin libraries found in the cube packages (using stm32f4cube 1.15.0), STemWin 532.

Peter.

Nesrine M_O
Lead II
Posted on April 18, 2017 at 10:25

Hi,

I am checking this issue with our team & come back to you.Sorry for the inconvenience it may bring.

-Nesrine-

Posted on April 26, 2017 at 09:55

Hi Nesrine,

Any update on this one yet?

Many Thanks,

Peter.

Giuseppe Cannarella
Associate II
Posted on May 23, 2017 at 08:49

Hi Nesrine,

can you estimate a date when the IAR 8.xx compatible release will be available?

At this moment I cannot migrate to IAR 8.xx due this library issue... but I need to do that as soon as possible.

Thank you.

Giuseppe

Posted on May 23, 2017 at 10:59

Hi

Cannarella.Giuseppe

,

The issue is noted and will be fixed soon in coming firmware release.Sorry for the inconvenience it may bring.

-Nesrine-

Posted on August 21, 2017 at 08:17

Hi

ELMHIRI.Syrine

‌ is there already an 8.xx compatible release? I need to use the osxMotionFx library of the Cube package in IAR 8.

Posted on August 29, 2017 at 15:23

Hi

ELMHIRI.Syrine

I have the same issue. When is the coming firmware release scheduled?

Kind regards

Jes Holm

Posted on August 29, 2017 at 15:41

What's IAR rationalization for wchar being 32-bit? Seems like a choice that would cause endless headaches.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on August 29, 2017 at 16:35

Broader support for unicode characters I guess? The size of wchar_t is not defined in the C standard, so compilers are free to choose whatever size and/or signedness they prefer in order to fully support whatever character encodings they want to support, and generally this shouldn't be a cause of headache, well except for situations like this when there is a compiled blob without source code which you want to use, and your ABI is different. More reasons to use open source

GCC has the -fshort-wchar option which forces wchar_t to be 'short unsigned int' (2 bytes) on platforms where it has a different type. Maybe IAR has a similar option?