2017-04-13 12:11 AM
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.
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
Solved! Go to Solution.
2018-06-01 01:18 AM
Hi all
Sorry for the delay to come back to you!
As committed a new
forhttp://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-
2017-04-18 12:14 AM
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.
2017-04-18 01:25 AM
Hi,
I am checking this issue with our team & come back to you.Sorry for the inconvenience it may bring.
-Nesrine-
2017-04-26 02:55 AM
Hi Nesrine,
Any update on this one yet?
Many Thanks,
Peter.
2017-05-22 11:49 PM
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
2017-05-23 03:59 AM
Hi
Cannarella.Giuseppe
,The issue is noted and will be fixed soon in coming firmware release.Sorry for the inconvenience it may bring.
-Nesrine-
2017-08-21 01:17 AM
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.2017-08-29 08:23 AM
Hi
ELMHIRI.Syrine
I have the same issue. When is the coming firmware release scheduled? Kind regards Jes Holm2017-08-29 08:41 AM
What's IAR rationalization for wchar being 32-bit? Seems like a choice that would cause endless headaches.
2017-08-29 09:35 AM
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?