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.

Issue reproducing *.dat files on different PCs using CCS v3.3

I have a question on why/how running the same code on the same hardware, but on different PCs would produce different *.dat files.

I have a GEL file which does the following:

   1. Loads my COFF file: UpdateFlash.out.

   2. Configures, then opens a file to log script progress.

   3. Checks if COFF file loaded:

        (a) If load successful, logs success and continues at step 4.

        (b) If load fails, logs failure and continues at step xx.

   4. Sets up and runs the loaded program:

        (a) Logs a message indicating the code is running.

        (b) Sets a timer with a 3-second timeout and callback function to save data (step 5).

        (c) Runs the loaded code, which should execute the require functions in < 1 second, then continue in an infinite wait-loop

   5. Cancels the timer set in step 4.

   6. Halts the code execution.

   7. Uses the GEL_MemorySave() function to write out a Hexadecimal *.dat file.

   8. Exits the GEL Script, then CCS by doing the following:

        (a) Logs whether script completed or exited due to error.

        (b) Closes file opened for logging.

        (c) Removes CCS debug state

        (d) Exits CCS.

I am able to consistently produce the same *.dat file (checked using an MD5 hash) if run on the same PC. If run on different PCs (two others) with what I believe is the same version of CCS (see below), the *.dat files produced are different, but can readily be reproduced on each PC.

   CCS Info (from “Help->About...” menu option):

      •  Same on all three PCs

         – Version: 3.3.38.2

         – Integrated Development: 5.98.0.219 Texas Instruments

         – BIOS: 5.31.02

         – Code Generation Tools: v4.1.0

   • Same on two of the three PCs:

         – Board Revision: (00.00.84)

         – Target Silicon Revision: (00.00.A13)

   • Third PC:

         – Board Revision: (00.00.00)

        – Target Silicon Revision: (00.00.00)

 

Thanks,

Steve

  • Hi Steve,

    Would your provide the two *.dat files? That would help a lot.

    Thanks

    ki

  • Hi Ki,

    I attached the *.dat files from all three PC's I ran the code on.

    I expected these all these files to be identical, but as you will be able to see each one is different from the other.

    Thanks for your help,

    Steve

     

     

    Dat_files.zip
  • Thanks. The differences seem to always be at the same addresses for the all three files. Could you check and see if what is in the *.dat file is what is in that memory location? Basically check those addresses on all three targets and see if the memory contents is the same. I am trying to determine if the issue is actually with the generation of the *.dat files.

  • Hi Ki,

    I was able to verify what was in the *.dat files produced by my automated script is the same as what is written to the flash memory by setting a breakpoint in our code and saving out the memory contents using the "Memory Save/Load Utility" tool with the following Target settings:

    Location: 0x008000

    Page: Data

    Bytes" 18432

    I did the comparison for 2 of the three systems (PC1 & PC2).

    The output from the memory saves are attached.

    Thanks,

    Steve

    Flash_MemSave.zip
  • Yes it looks like the actual contents of memory differ between the targets, and the dat files are being generated correctly. I do not have any ideas on why the contents of memory would vary for the same application. I would need a reproducible test case (the *.out file). Also what exact target and emulator are you using?

  • Ki,

     

    Here's the information you requested:

    Emulator:       Spectrum Digital: XDS510USB

    DSP Target:   TMS320VC5416ZGU160

     

    Additionally,

    Flash Memory: SST39LF020 (256K x 8)

     

    Also, I attached the *.out & *.map file for the project.

     

    Thanks,

    Steve

    Project_Output_Files.zip
  • Ki,

    Do you need more information than what I have posted to attempt to answer this question?

    Thanks,

    Steve

  • yes I am fine for now. Thanks

  • Actually one thing that would be interesting is if you can try swapping boards. You say that the *.dat is always the same on the same PC. But what happens if you change the board that a particular PC is using?

  • Hi Ki,

    I had already tried swapping boards previously.

    I may have found a solution to my problem, but not necessarily an explaination as to how we get the results we did.

    I traced the contents of the *.dat files to the corresponding addresses of this data when it is loaded from flash to RAM when the system boots. What I found was that the discrepancies between *.dat files were associated with sections of unitialized RAM, stack and locations where a checksum for *.dat data was placed. I am now in the process of revising my programming check on the *.dat data to include only the data truly required for the application (i.e., Boot Table, code, constants, etc.).

    The puzzle to me now is why I am able to produce consistent results including all the *.dat in my verification check on a given system. However, if the above *.dat file verification works for us I do not need to solve this puzzle. I post my results either way.

    Thanks,

    Steve

  • Hi Ki,

    I was able to get the desired results by generating *.dat files with only the content that required checking.

    Still have no idea what happened to produce the original results.

    Thanks for looking into this.

    Steve