• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 3821 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS1224: Flash library F021 and wchar_t problem with IAR compiler

Christian Welzel
Prodigy 40 points
Part Number: TMS570LS1224

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:

  • 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_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

  • 0
    TI__Guru 59540 points
    Hello Christian,

    Thanks for posting to the public E2E and for the additional information. As I am not an expert on these aspects of the F021 Flash API software, I am forwarding this to our Software lead for his comments/support on how it can be addressed.
  • 0 in reply to Chuck Davenport
    Prodigy 40 points

    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:

    C/C++

    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

    "an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales" (ISO 9899:1990 §4.1.5)

    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:

    "The width of 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: https://en.wikipedia.org/wiki/Wide_character#C.2FC.2B.2B

    May be this could help to fix the problem. Thanks.

    Kind regards,

         Christian

  • 0 in reply to Chuck Davenport
    Prodigy 40 points

    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:

    C/C++

    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

    "an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales" (ISO 9899:1990 §4.1.5)

    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:

    "The width of 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

  • 0
    Prodigy 90 points

    Hi,

    has the above issue been resolved? I have a similar problem.  One option is to downgrade  IAR EWB so that is compatible with two byte whcar_t used in the library

  • 0 in reply to Mandeep Panesar
    Prodigy 40 points

    Hi,

    that's correct. We could downgrade the IAR Workbench but we won't. So the problem is still remaining.

    I think both parties are involved within this issue. It's not only the compiler, it's also the wrong data type which is used.

    Please solve the problem. Thanks.

    Regards,

         Christian

  • 0 in reply to Christian Welzel
    TI__Mastermind 35905 points
    Hi,

    Due to mismatch in the wchar_t datatype size, F021 Flash library version 02.01.01 is not compatible with the latest IAR compiler.
    There is no library available built with wchart_t as 4 bytes. Also, there is no short term plan of supporting such a library.
    The only workaround for now is to downgrade the IAR Workbench.

    Thanks & Regards,
    Siddharth