- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi,
we use the F021 Flash Library for the EEPROM emulation and it works fine with the IAR Workbench for ARM v8.11.1. With the latest version 8.11.3 there is a big problem. The library doesn't work anymore. The program still stucks at the busy flag and erase flag check after the flash erase command.
The warning (error) message of the IAR Workbench is as follows:
IAR ELF Linker V8.11.3.13950/W32 for ARM
Copyright 2007-2017 IAR Systems AB.
Warning[Lt009]: Inconsistent wchar_t size
FlashStateMachine.EnableEepromSectors.obj(F021_API_CortexR4_BE.lib) and 17 other objects have wchar_t size 16 bits
adc.o and 256 other objects have wchar_t size 32 bits
Warning[Li026]: the module "FlashStateMachine.EnableEepromSectors.obj(F021_API_CortexR4_BE.lib)" (and 17 other modules) do not contain information to support Virtual
Function Elimination
++ The following sections would have been initialized by copy but were
excluded because they were marked as possibly 'needed for init':
.text:Fapi_calculateFletcherChecksum (Utilities.CalculateFletcher.obj(F021_API_CortexR4_BE.lib) #11)
.text:Fapi_initializeFlashBanks (FlashStateMachine.InitializeFlashBanks.obj(F021_API_CortexR4_BE.lib) #12)
.text:Fapi_issueAsyncCommand (Async.obj(F021_API_CortexR4_BE.lib) #11)
.text:_Fapi_divideUnsignedLong (FlashStateMachine.InitializeFlashBanks.obj(F021_API_CortexR4_BE.lib) #11)
.text:_Fapi_issueFsmCommand (FlashStateMachine.IssueFsmCommand.obj(F021_API_CortexR4_BE.lib) #11)
.text:_scaleEEFclk (FlashStateMachine.ScaleFclk.obj(F021_API_CortexR4_BE.lib) #13)
.text:_scaleMainFclk (FlashStateMachine.ScaleFclk.obj(F021_API_CortexR4_BE.lib) #12)
It seems to be a problem with the wchar_t definition. IAR wchar_t is 4 bytes and the library uses 2 bytes for wchar_t.
Is there a library build with 4 bytes wchar_t available?
The only information from IAR about the change of the wchar_t is as follows:
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.
wchar_taspect this has the following implications:
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.
Could be found here: netstorage.iar.com/.../iccarm.ENU.html
Any ideas?
Kind regards,
Christian
Hello Chuck,
I think, the problem is the used data format wchar_t. This is compiler defined and could from 8 bits to 64 or more bits. The C and C++ standard defines in the 2011 version two new data types char16_t and char32_t. These types are the better decision for the flash library.
A small comment about the data types can be found at the Wikipedia:
The C and C++ standard libraries include a number of facilities for dealing with wide characters and strings composed of them. The wide characters are defined using datatype wchar_t, which in the original C90 standard was defined as
Both C and C++ introduced fixed-size character types char16_t and char32_t in the 2011 revisions of their respective standards to provide unambiguous representation of 16-bit and 32-bit Unicode transformation formats, leaving wchar_t implementation-defined. The ISO/IEC 10646:2003 Unicode standard 4.0 says that:
wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers."Link: 
May be this could help to fix the problem. Thanks.
Kind regards,
Christian
