• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 537 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.

TMS320C6747 -- reading (back) L1P

Gary Parnes
Prodigy 60 points

Hello,

I'm having a problem with some code that is attempting to verify a DMA transfer of code from external SDRAM to L1P RAM.

The code starts off with interrupts enabled, and L1P, L1D and L2 configured as cache.  Here is the general sequence of events from that point:

HWI_disable();

BCACHE_wbInvAll();

BCACHE_getSize( &oldSizes );
newSizes.l1psize = BCACHE_L1_0K;
newSizes.l1dsize = BCACHE_L1_0K;
newSizes.l2size = BCACHE_L2_0K;
BCACHE_setSize( &newSizes );
BCACHE_invL1pAll();
BCACHE_wbInvAll();    /* because I'm paranoid */

/* EDMA transfer setup occurs here... transfer from SDRAM address to 0x11E00000 primed */


BCACHE_wbInvAll();    /* because I'm paranoid (again) */

BCACHE_invL1pAll();  /* and again... */

/* EDMA transfer is manually triggered... code then busy-waits for EDMA transfer to complete... */

BCACHE_wbInvAll();    /* this is getting silly... */

BCACHE_invL1pAll();  /* sillier... */

After the above sequence, the code then tries to read back L1P and compare it against the source buffer:

        if( LoadAddress == 0x11E00000 )
        {
            Uint32 i;

            for(i = 0 ; i < Size ; i++)  /* Size is number of 32-bit words in source buffer */
            {
                const Uint32 jj = ((Uint32*) LoadAddress)[i];
                const Uint32 kk = ((Uint32*) (SourceBuffer)[i];

                if( jj != kk )
                {
                    asm volatile("  nop;");   /* debugger landing zone... something went wrong... */
                    asm volatile("  nop;");
                    asm volatile("  nop;");
                    asm volatile("  nop;");
                }
            }
        }

The odd thing is, the comparisons between the source and destination (jj and kk) fail on virtually every word, yet...

--The code in L1P still executes properly when I branch to it.  That is, by all indications, the transfer succeeded.

--Code Composers Memory window shows that the contents of 0x11E00000 and &SourceBuffer match up perfectly. (Again, indication that the transfer succeeded)

 

The data sheet says that I should be able to read L1P directly.  So what am I doing wrong?

 

Thanks.

  • 0
    TI__Guru*** 125430 points

    I've always been under the impression that the CPU can neither read nor write L1P SRAM.  However, when I went to grab the supporting documentation this is what I saw:

    spru871j.pdf Chapter 2.3.1.2 said:

    The L1P regions can only be written to using EDMA or IDMA accesses; the L1P regions cannot be written
    to using CPU stores. The L1P regions can be read from using EDMA, IDMA, or CPU accesses.

    According to that, the L1P can actually be read using CPU, though not written.  That said, the only other thing I can think of would be to try reading the local address (0x00E0_0000) instead of the global address (0x11E0_0000).

    Brad

     

  • 0 in reply to Brad Griffis
    TI__Genius 17355 points

    SPRU871 Section 2.9.1.2: "The CPU cannot directly access L1P RAM and ROM via load and store instructions."

    When it states earlier that the CPU can access the L1P, it must only mean for instruction fetches.  In fact, that statement that Brad quotes from 2.3.1.2 was not in the original version of the document that I had (rev. F).

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 60 points

    The section that Brad quoted is exactly what led me to believe that I could read back L1P using standard load instructions.  I think "CPU accesses" is not concise enough; it does not draw a distinction between instruction fetches and data fetches.

    Can we expect 2.3.1.2 to be modified in the next revision of the document?

    Thanks,

    --Gary

     

  • 0 in reply to Gary Parnes
    TI__Genius 17355 points

    I've gone ahead and filed a documentation feedback by clicking on the link at the bottom of the page of the pdf.  Please feel free to do the same if you'd like. My comment in the feedback was as follows:

    The statement in section 2.3.1.2: "The L1P regions can be read from using EDMA, IDMA, or CPU accesses." is confusing since the CPU cannot read L1P memory using conventional load/store routines(see section 2.9.1.2). It seems that this statement is indicating that the CPU can read this memory via instruction fetches. If that is the case, the statement should be modified to something like the following: "The L1P regions can be read from using EDMA, IDMA, or CPU instruction fetch accesses." Possibly a reference here to section 2.9.1.2 would also be useful.

     

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 60 points

    Will do.  Thanks very much for getting me straight.

     

    --Gary