• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 54 subscribers
  • Views 1347 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.

Original question:

startup_ARMCA15.S in CCS 6.1.3 can cause an Undefined Instruction Exception when enabling the VFP

CCS/EVMK2EX: Undefined Instruction caused during startup code when using option -mfloat-abi=hard with EVMK2E device.

Jasvinder Marwaha
Prodigy 245 points
Part Number: EVMK2EX
Other Parts Discussed in Thread: AM3358, AM5728, AM1705, CCSTUDIO

Tool/software: Code Composer Studio

I am running a simple bare metal program on the EVMK2E development kit but when enabling neon/hard floating point arithmetic it causes an undefined instruction. It appears that the coprocessors are not being enabled properly or in time. 

It seems similar to the issue mentioned in the related question here https://e2e.ti.com/support/tools/ccs/f/81/t/531151 . I can confirm using the debugger that This is identical to startup code that I have run successfully on both AM3358 and AM5728. Targeting an A15 core on both AM5728 and EVMK2E.

I am using CCSv8. In the thread above the TI employee never got back with test results so I do not know of any official solution to this issue? This problem exists even in a pregenerated hello world project from CCS tools after enabling the VFP in project settings. I am currently trying to locate the CPACR register to verify its value.

Project Device - K2GEVM

Linker - 66AK2Gxx.lds

Compiler - GNU v7.2.1

Summary of flags: -mcpu=cortex-a15 -mtune=cortex-a15 -marm -mfloat-abi=hard -mfpu=neon -Dk2g02 -DAM5K2E02 -Darm0 -Os -ffunction-sections -fdata-sections -g -gdwarf-3 -Wall -specs="rdimon.specs"

  • 0
    Prodigy 245 points
    It seems I've been able to solve this in the debugger at least. The CPACR register appears to not be able to be written to, but I used a slightly different GEL initialisation script (evmk2e_arm.gel) located at C:\ti\ccsv8\ccs_base\emulation\boards\evmk2e\gel instead of evmk2e.gel which appears to solve that problem.

    As I need to be able to access these registers from bare metal startup (no script) I will post what this other .gel does to enable read/write when I find it. (I think it is likely to be the NSACR).

    Thanks.
  • 0 in reply to Jasvinder Marwaha
    TI__Guru**** 171044 points
    Hi,

    The original thread you linked certainly seems to be the root cause for this behaviour. Unfortunately I ended up dropping that thread, but another discussion took place at a later time which resulted in creating the bug report CCSIDE-3476. This bug is fixed for the upcoming release of CCS (CCSv9).

    Due to other priorities, a definitive fix for CCSv8 and earlier was not released, but its workaround is simple and described in the workaround section of the bug report, which can be seen in the link SDOWP in my signature below, and consists of the following:

    "manually add the ISB opcode at line 97 of the startup file being used: either startup_ARMCA9.S or startup_ARMCA15.S"

    A new release of this file will be available soon for CCSv8.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    A new release of this file will be available soon for CCSv8.

    A CCS 8.3 installation under Linux showed the following updates available:

    - Shared device support 1.1.1
    - Sitara device support 1.4.5

    Where the description of the updates was:

    THIS UPDATE IS EXCLUSIVE FOR CCSv8 AND EARLIER. The update contains improvements and bug fixes, including:

    - Fixed CCSIDE-3476 (VFP initialization fails to complete)

    However, these updates break startup_ARMCA9.S and startup_ARMCA15.S:

    1. Start with Shared device support 1.1.0 and Sitara device support 1.4.4 installed.

    ccsv8/ccs_base/arm/include/startup_ARMCA15.S is 6593 bytes, dated Mar  3  2015, and doesn't include the ISB instruction.

    ccsv8/ccs_base/arm/include/startup_ARMCA9.S is 6590 bytes, dated Dec  1  2015, and doesn't include the ISB instruction.

    2. Let CCS 8.3 update to Shared device support 1.1.1 and Sitara device support 1.4.5

    ccsv8/ccs_base/arm/include/startup_ARMCA15.S is now an empty zero-byte file dated Mar  9  2019

    ccsv8/ccs_base/arm/include/startup_ARMCA9.S has been deleted.

    3. I have switched between Shared device support 1.1.0 / 1.1.1 and Sitara device support 1.4.4 / 1.4.5 a few times to check this is a repeatable problem with the updates, rather than one-off glitch during the initial install of the updates. 

  • 0 in reply to Chester Gillon
    Guru 92251 points

    Chester Gillon said:
    A CCS 8.3 installation under Linux showed the following updates available:

    - Shared device support 1.1.1

    - Sitara device support 1.4.5

    However, these updates break startup_ARMCA9.S and startup_ARMCA15.S:

    Device support files - Sitara AMxxxx has links to zip files for shared_device_support_1.1.1.zip and sitara_device_support_1.4.5.zip. When those zip files were extracted into the CCS 8.3 installation got updated startup_ARMCA9.S and startup_ARMCA15.S files containing the ISB instruction.

    I.e. the standalone zip files for Shared device support 1.1.1 and Sitara device support 1.4.5 are valid, and the problem appears to be invalid updates for those made available to the CCS "Check for Updates".

  • 0 in reply to Chester Gillon
    TI__Guru**** 171044 points
    Chester,

    The installer is somehow writing a zero-byte startup_ARMCA15.S file for some unknown reason.

    If I download the .jar package from the server and extract it, the file is correct. The p2 installer is somehow corrupting the install.

    I will have to investigate this with other folks, as this is not under my realm. The package is being correctly generated.

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 171044 points
    Chester,

    I am doing several tests on the update site and there is still something not quite right when accessing the update site from the external public link.

    In other words, I am able to install the updates when I use an internal link that points to the exact same update site, thus ruling out any corruption or invalid files from it.

    Also, a previous version of CCS (8.2) was successfully updated from the public link, although I was not able to test more than one instance of CCS.

    The investigation continues and, at the moment, the only reliable workaround is to extract the .ZIP file at the Device support files page you linked above.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    The installer is somehow writing a zero-byte startup_ARMCA15.S file for some unknown reason.

    An offline install of CCS 9.0.0.00018 under Ubuntu 18.04 installed Shared Device Support 1.1.1 and Sitara Device Support 1.4.5. With this initial installation there was a ccs/ccs_base/arm/include/startup_ARMCA15.S present with the ISB instruction.

    On starting CCS 9 for the first time, CCS said some updates were available including Shared device support 1.1.2 and Sitara device support 1.4.6. After installing the updates startup_ARMCA15.S became a zero-byte file. I.e. the problem is still apparent with CCS 9. I had a look at the install logs, but couldn't see an obvious error.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    Chester Gillon said:
    After installing the updates startup_ARMCA15.S became a zero-byte file.

    I had a look at the changes in the CCS installation files between:

    a. Installing CCS 9.0.0.00018 (with only support for Sitara devices selected)

    b. Installing the updates for Shared device support 1.1.2 and Sitara device support 1.4.6.

    Investigating showed after performing the updates:

    1. ccs/ccs_base/arm/include/AM1705.cmd and ccs/ccs_base/arm/include/startup_ARMCA15.S became zero byte files.

    2. The workspace .metadata/.log file had the following errors:

    !ENTRY org.eclipse.equinox.p2.touchpoint.natives 4 0 2019-03-23 18:10:35.453
!MESSAGE org.eclipse.equinox.internal.p2.touchpoint.natives.actions.UnzipAction error unzipping zipfile: /home/mr_halfword/ti/ccs900/ccs/eclipse/downloads/shared_device_support_1.1.2.zipdestination: /home/mr_halfword/ti/ccs900/ccs/eclipse/../ccs_base

!ENTRY org.eclipse.equinox.p2.touchpoint.natives 4 0 2019-03-23 18:10:35.458
!MESSAGE org.eclipse.equinox.internal.p2.touchpoint.natives.actions.UnzipAction error unzipping zipfile: /home/mr_halfword/ti/ccs900/ccs/eclipse/downloads/sitara_device_support_1.4.6.zipdestination: /home/mr_halfword/ti/ccs900/ccs/eclipse/../ccs_base

    3. ccs/eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/com.ti.ccstudio.shared.devicesupport_root_1.1.2 was a zip file which contained downloads/shared_device_support_1.1.2.zip. unzip -l showed the first file in downloads/shared_device_support_1.1.2.zip was:

    Archive:  /tmp/downloads/shared_device_support_1.1.2.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2018-04-02 15:38   arm/
        0  2019-03-08 14:05   arm/include/
     6657  2019-01-18 15:39   arm/include/startup_ARMCA15.S

    ccs/eclipse/p2/org.eclipse.equinox.p2.core/cache/binary/com.ti.ccstudio.sitara.devicesupport_root_1.4.6 was a zip file which contained downloads/sitara_device_support_1.4.6.zip. unzip -l showed the first file in  downloads/sitara_device_support_1.4.6.zip was:

    Archive:  /tmp/downloads/sitara_device_support_1.4.6.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2018-06-12 14:12   arm/
        0  2019-03-08 14:05   arm/include/
     2404  2012-03-21 08:42   arm/include/AM1705.cmd

    4. I.e. the files which became zero bytes were the first files in the zip archives for which the CCS .log reported "org.eclipse.equinox.internal.p2.touchpoint.natives.actions.UnzipAction error unzipping zipfile" errors.

    5. When strace was used to watch the CCS update which created the zero byte files can see the sequence:

    a. Renames the original file in the CCS installation to be in a /tmp directory.

    b. Create a zero bytes file in the CCS installation.

    c. Write the "\n!ENTRY org.eclipse.equinox.p2.t"... error to the .log file.

    22641 rename("/home/mr_halfword/ti/ccs900/ccs/ccs_base/arm/include/startup_ARMCA15.S", "/tmp/epp.package.cpp_2d3577e9dc20_7f000101861b/_/home/mr_halfword/ti/ccs900/ccs/ccs_base/arm/include/startup_ARMCA15.S") = 0
22641 stat("/home/mr_halfword/ti/ccs900/ccs/ccs_base/arm/include/startup_ARMCA15.S", 0x7f8eeee38ba0) = -1 ENOENT (No such file or directory)
22641 openat(AT_FDCWD, "/home/mr_halfword/ti/ccs900/ccs/eclipse/../ccs_base/arm/include/startup_ARMCA15.S", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 83
22641 fstat(83, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
22641 close(83)                         = 0
22641 close(69)                         = 0
22641 stat("/home/mr_halfword/workspace_v9/.metadata/.log", {st_mode=S_IFREG|0644, st_size=37647, ...}) = 0
22641 openat(AT_FDCWD, "/home/mr_halfword/workspace_v9/.metadata/.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 69
22641 fstat(69, {st_mode=S_IFREG|0644, st_size=37647, ...}) = 0
22641 write(69, "\n!ENTRY org.eclipse.equinox.p2.t"..., 329) = 329
22641 close(69)                         = 0

    Not sure what is causing the org.eclipse.equinox.p2.touchpoint.natives to create a zero byte file and the abort processing the zip file. Has there been a change to the p2 installer between CCS 8.2 which didn't show the problem, and CCS 8.3 and CCS 9.0 which show the problem?

  • 0 in reply to Chester Gillon
    TI__Guru**** 171044 points
    Chester,

    Thanks for the additional insights. I have been investigating this as well in the past few weeks but could not find a difference in the p2 touchpoint component that justifies this issue. I am hedging my bets on either a change in the .zip file compression (IT blocked my beloved WinRAR in favour of 7-Zip) or something related to a required change in the signature (which also changed in February).

    As you can tell, I am grasping for straws at the moment. However, I was able to install this package in 8.3 for Windows, but not 8.3 for Linux nor 9.0 for both OSes.

    I will definitely let you know about my progress.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 171044 points

    Chester,

    I fiddled with the 7-Zip settings and was able to create an installable package on both Windows and Linux on my v9.0.0. The trick that worked for me was to compress the file with a single thread and leaving everything else as the most standard possible. I guess its defaults were too aggressive for touchpoint.



    Please give this a try tomorrow (to let the server pick up the changes) and see if it works.

    Regards,
    Rafael

  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    Please give this a try tomorrow (to let the server pick up the changes) and see if it works.

    That worked with CCS 9.0 under Ubuntu 16.04. Thanks.

  • 0 in reply to Chester Gillon
    TI__Guru**** 171044 points
    Thanks for reporting back your findings. I apologize for the troubles.