• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1689 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.

TMDSIDK437X: Problem with code loading in custom board

Jacek Jaworski
Expert 1325 points
Part Number: TMDSIDK437X
Other Parts Discussed in Thread: AM4377, SYSBIOS

Hi,

I am trying to migrate my project written on the idkam437x with ccs 6.1.2 and sysbios 2.1.1.2 to the custom board with am4377 processor. A new target configuration for am4377 was set and new gel files were provided based on the idkam437x gel files - PLLs and DDR was succesfully initialized - as in original idkam437x board. The problem exists when I want to download the project written for idkam437x to my custom board: the following info was displayed:

CortexA9: File Loader: Verification failed: Values at address 0x00000000800080DC do not match Please verify target memory and memory map.
CortexA9: GEL: File: C:\...\project.out: a data verification error occurred, file load failed

The problem seems to be related to the memory(linker?) settings and I see that this error is quite common - even the tutorial was provided which I was trying to follow but the problem still exists:

Before downloading the project I changed some project options:

As I use sysbios, the linker file should now be prepared automatically - or should I set the processor type somewhere else in the sysbios cfg file?

One thing that seems bad for me is problem with memory view. The DDR afer initialization looks OK:

However, the rest of memory looks unaccessibly:

Maybe the memory was not initialized properly? I see no memory initialization in GEL files but there was no such initialization in original idkam437x GEL files too and there were no problems with code downloading.

Could you please help me with that issue?

Thanks!

JJ

Edit:

The OCMC SRAM looks accessible but I suppose it is not the place where the code is being downloaded:

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0
    TI__Guru*** 125430 points

    Jacek Jaworski said:
    CortexA9: File Loader: Verification failed: Values at address 0x00000000800080DC do not match

    This address is in DDR.  The most likely reason it's failing is because DDR was either not configured (via gel) or not configured correctly via gel.  If your data has a bit flip, missing byte, etc. then you will end up with a data verification error.  Are you positive DDR is rock solid?  A simple test that's a good start is to simply maximize a memory window and refresh it a bunch of times.  Perhaps poke in a few random bytes of data to make sure nothing else is impacted except for the exact address you modified.  It's usually pretty clear if things aren't stable as you will see words turning red as the contents change.

  • 0 in reply to Brad Griffis
    Expert 1325 points
    Hi Brad,
    thank you very much for fast answer,
    Indeed we had a huge problem with DDR initialization at the beginning - it was posted on E2E: e2e.ti.com/.../559861
    A few days ago we acquired a set of 'not bad' settings as our tests for DDR write/read operations in GEL files were positive during the last week - not a single error was detected for approx. 60 hours of constant DDR work (I know this is not sufficient for the 'industry' level).
    Regards,
    JJ
  • 0 in reply to Jacek Jaworski
    TI__Guru*** 125430 points

    You may want to open a memory window to view the precise area of memory impacted.  For example, with the error reported at 800080DC you should at a minimum view 800080D0 - 800080FF.  Perhaps you could compare what's observed on your board with what's observed on an IDK.  That will help you to determine the nature of the failure, i.e. is it a bit flip, etc.

  • 0 in reply to Brad Griffis
    Expert 1325 points

    I watched the memory browser in both two cases and found an interesting thing.

    In IDKAM437X the code is downloaded from the start address 0x800080DC:

    whereas in the custom board the starting address is much lower and, as a result, the memory table is totally different:

    Could it be a problem that the start address is different in both cases? - I do not see any reason for that. That makes the memory table analysis quite hard.

    Could the overall problem be related to the lack of some hardware settings (e.g. platform, address, processor family) somewhere in the project(sysbios) or target configuration?

    Thanks

    JJ

  • 0 in reply to Jacek Jaworski
    TI__Guru*** 125430 points
    You should be loading the exact same out file to each board. I don't see how they could possibly be different with respect to how they are being loaded. The only thing that should be different is the gel file used when connecting, i.e. that's what accounts for the differences in DDR being used.
  • 0 in reply to Brad Griffis
    Expert 1325 points

    That project is the only project in my workspace right now so I am absolutely sure that is the same out file - my thought was that the same binary is downloaded to different directories in the boards and, as a result, the parts of code read from the address range 0x800080D0 - 0x800080FF seem to be different (I do not know what is the start address in the custom board).

    I cannot find any code in IDKAM437X's  GELs that stands for memory maping, debugger map or setting any start address for the code etc. Should there be any, or it ends with basic DDR initialization and write/read test know from AM43xx_EMIFconfig_HWlvl file?

    Regards,

    JJ

  • 0 in reply to Jacek Jaworski
    TI__Guru* 95265 points
    JJ,

    You can look at your .map file how the memory is used, the entry point of the code is _c_int00. What code it is for this 0x800080D0 - 0x800080FF region? .text? Do you have any DDR R/W test for this region to make sure DDR is OK? Or you can change the linker command file to put things in OCMC or other DDR regions to isolate the problem?

    Regards, Eric
  • 0 in reply to lding
    Expert 1325 points

    Hi Eric and Brad,

    The problem looks solved after many attempts and the solution looks trivial for me.

    The bug in DDR configuration is associated with page size in DDR config register

    What is pretty weird, this parameter was determined by me, Brad and Memory supplier at the other E2E thread e2e.ti.com/.../559861 to be equal to 11 column (based on datasheet). When I changed it to be 10-column page size the problem has vanished. The code can be downloaded and all the short DDR tests look OK but I don't know if the new parameter is really OK...

    Anyway, thank you all for your help.

    JJ

     

  • 0 in reply to Jacek Jaworski
    TI__Guru*** 125430 points

    Great news!  (Mostly...)  That's really odd.  I recommend further exploring that difference with your memory manufacturer.  Is theirdata manual incorrect?  Did they ship you the wrong part?  Thanks for reporting back.

  • 0 in reply to Brad Griffis
    Expert 1325 points

    Yes, you are right - we need to thoroughly analyze the mismatch - it is only my guess, but I suppose there is some error in the memory manual.

    If I get any interesting information, I will share it here.

    Thanks again,

    JJ