• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 603 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28377S: Error loading ELF file with UniFlash

Jeremie Snyder
Prodigy 50 points
Part Number: TMS320F28377S
Other Parts Discussed in Thread: UNIFLASH

UniFlash is giving a file type error (full console output below) when attempting to load an ELF file. I have no issues when loading a legacy COFF file, but I'm trying to update to EABI.

Inspecting the file using the unix file utility outputs the following:

$ file app.elf
app.elf: ELF 32-bit LSB executable, TI TMS320C2000 DSP family, version 1 (SYSV), statically linked, with debug_info, not stripped

Relevant tools versions: UniFlash version 3.4.1, CGT version 20.2.3.LTS

UniFlash Console Output:

[09:14:28] Begin Launching session operation.
[09:14:33] Operation Launching session returned. 
[09:14:33] Loaded target configuration from: C:\Users\<redacted>\config.ccxml
[09:14:37] Start operations on multiple programs on the target core...
[09:14:39] C28xx_CPU1: GEL Output: 
Memory Map Initialization Complete

[09:14:40] Loading program: C:\Users\<redacted>\app.elf
[09:14:40] ERROR >> C28xx_CPU1: GEL: Encountered a problem loading file: C:\Users\<redacted>\app.elf Could not determine target type of file

[09:14:40] Encountered a problem loading file: C:\Users\<redacted>\app.elf
Could not determine target type of file
[09:14:40] Programs operation finished.

The release notes for UniFlash 3.4.1 claim to support both TI COFF and TI ELF, so I'm not sure what the problem is here.

  • 0
    TI__Guru**** 160560 points

    Jeremie,

    UniFlash 3.4.1 is very old and would support ELF for Arm based devices.  However that release was done before ELF was a supported output for C2000.  You will need to use a newer version of UniFlash.

    https://www.ti.com/tool/UNIFLASH

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 50 points

    John,

    The reason I'm still using UniFlash 3.4 is because it seems that newer releases removed support for programming multiple target devices on a single JTAG chain. I have tried v6 but was unable to program my target using my *.ccxml file.

    Maybe I'm missing something though with configuring the ccxml file properly for use with UniFlash v6?

  • 0 in reply to Jeremie Snyder
    TI__Guru**** 160560 points

    Jeremie,

    It is possible to do this in newer UniFlash releases but is defintely more complicated.  I will loop in someone else to provide more details.

    Regards,

    John

  • 0 in reply to Jeremie Snyder
    TI__Guru**** 433951 points

    Jeremie Snyder said:

    The reason I'm still using UniFlash 3.4 is because it seems that newer releases removed support for programming multiple target devices on a single JTAG chain. I have tried v6 but was unable to program my target using my *.ccxml file.

    Maybe I'm missing something though with configuring the ccxml file properly for use with UniFlash v6?

    You are correct, this is a limitation with the current versions of UniFlash. There is an open request to address this issue. Tracking ID for this request is: https://sir.ext.ti.com/jira/browse/EXT_EP-9784

    In the meantime, a workaround as mentioned by John in the below thread can be used:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/800192

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    I've followed the instructions to create multiple ccxml configurations with only one device enabled in each, but the UniFlash GUI seems to just be broken. The "Load Image" button doesn't work. It will initially try and connect to the debug probe but then it doesn't flash. After that, the button just does nothing. At no point does any info appear in the console, even if verbose mode is turned on. The "Verify Image" button does the same thing and it won't read target device memory either. I'm at a loss for how the functionality of this program could have regressed so badly since v3.4.

    Fortunately, I was at least able to get the standalone command line tool to work and successfully programmed using the dslite tool.

    Unfortunately, none of my devices are booting now after a power reset.

    Is UniFlash/dslite changing DCSM boot settings or something? I am relying on the default boot get/flash mode set via the default GPIO boot select pins.

  • 0 in reply to Jeremie Snyder
    TI__Guru**** 433951 points

    If you use the CCS IDE, are you able to successfully flash each device successfully using the new ccxml files with the bypasses? 

  • 0 in reply to Ki
    Prodigy 50 points

    Yes, I can program and debug via the ccxml files in CCS. Same result as dslite though, the program runs fine after programing, but won't boot after a reset.

    I'm wondering if maybe I missed something when migrating from COFF to EABI and there's now an issue where my program isn't getting loaded into the correct location. Could the GEL script be masking an issue here during program load that would then only show up on a target reset?

  • 0 in reply to Jeremie Snyder
    Prodigy 50 points

    I seem to have solved the booting issue.

    As I was suspecting above, there is a change in behavior with EABI vs COFF. The TI provided linker command file which defines all the peripheral registers (F2837xS_Headers_nonBIOS.cmd) does not set type=NOINIT. When compiling for EABI,  _c_int00 zero-initializes all of these registers. This performs an invalid write to WdRegs.WDCR.bit.WDCHK and immediately trips the watchdog.

    The GEL init script disables the watchdog before programming, but my application code disables the watchdog as soon as it branches to main(), so this behavior was hidden upon initial programming.

    Disabling the watchdog before branching to _c_int00 causes the write to WDCHK to be ignored and fixes the issue. Setting type=NOINIT in the linker command file for these registers would probably also fix the issue.