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

uPP not writing data to memory

Michael Greenspan
Intellectual 575 points
Other Parts Discussed in Thread: OMAP-L138

I am using an OMAP-L138 evaluation board for developing a C6746 application.  The ARM processor is not involved...it sits in a loop monitoring the serial port.

I have set up the uPP for the simplest possible use as a receive only on a single channel with a slow clock.  From the uPP status registers, it seems to do everything I wanted it to do...I set it up with a line of 8192 bytes, 2 pages, and a line offset of 8192.

I clock it and watch the status registers for the byte count and line count incrementing each 64 bytes, and the current address as well, exactly where it appears in the map file.  The EOLI and EOWI bits appear as they ought at the right times when I reach the 1st line and 2nd line.

Only problem is that nothing gets written to memory, except in one.   If I use shared RAM at 0x8000 0000, it writes the data OK (except for some reason not the 1st 256 bytes??).  If I split L1D to 16K of cache and 16K of data, it does not work  If I use L2 RAM, it does not work.  Are there some special tricks that need to be taken to allow the DMA of the uPP to write data?  Or some limitations that I have not found?  (I tried doing a cache invalidate when using L2RAM, and viewing L2RAM directly with the debugger, and no data enters it...I fill the whole buffer with a pattern 0xDEAD so that it will be clear if it is written).

No interrupts are enabled.   I see in the UPISR register a value of 0x20 ( reserved bit set).  When the end of line occurs, it changes to 0x34...that is, end of line, but also, the internal bus error condition.  I could not find any documentation on what causes the latter.

Any help would be much appreciated.  I have a feeling that I am missing some small point.

Thanks

  • 0
    TI__Guru** 116100 points
    Hi,
    Did you configure the L1 and L2 RAM properly ?
    Able to write any data into that L1/L2 RAM through CCS's "memory browser" ?
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 575 points
    Thank you for your ideas.

    There is no problem writing the L1/L2 RAM using the CCS memory browser.
    L2RAM is configured as non-cache memory, which is the default at reset. To verify this, I looked at the L2CFG register at location 0x01840000 and it shows me a value of 0x01010000. Decoding the bits, this tells me that there are two modules, which is correct for the OMAP-L138, and that the DSP is the second of them, which is also correct, and that the L2 memory is configured with cache disabled (Table 4.11 of the MegaModule reference guide tells about the register, and its location is in the OMAP-138 data sheet.
    L1DRAM I have configured as 16K of cache and 16K of data memory. This was done using the L1DCFG register, setting to value 0x03, and reading it back to confirm...using an instruction:

    HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1DCFG) = 3;

    Now, the funny thing is, it works perfectly well if I write to L1DRAM or L2RAM using the high addresses that are available to the OMAP-138 or C6748, at addresses 0x11F00000 (for L1D RAM) or at 0x11830000 (for L2RAM). (The problem I mentioned earlier of the first 256 bytes is fixed.)

    I have checked the L1DMPPA16-31 registers...these are for memory protection...they are all at their default values of 0xFFF6, meaning that all master IDs can read or write, but not execute from this memory. That is as expected. For L2RAM, they are at default values of 0xFFFF, meaning no protection.

    Also, in the UPISR register, when I use the addresses that work, (0x11830000 or 0x11F00000), the internal bus error condition is not set. The EOLI and EOWI bits get set exactly at end of line and end of window respectively. However, when I use the addresses 0x000830000 or 0x00F00000 (for the same physical memory), the EOLI bit does not get set, but rather the internal bus error. The EOWI gets set when the end of window is reached. But no data is actually written into the memory.

    Could it be that this is an undocumented feature of the UPP DMA? Or is there some aspect of the uPP setup or memory protections that I am missing?

    Any help would be most welcome.
  • 0 in reply to Michael Greenspan
    Intellectual 575 points

    I found this post on a different thread, regarding a question as to why there are two different addresses for L1P and L1D and L2 memory.  The answer given was a follows:

    wu wu,

    This really should be explained in the datasheet, but I could not find it either. I search for "local" and "global" and neither showed up in this type of explanation. Sorry about that.

    The C674x DSP Megamodule contains the L1 and L2 memories. Only the DSP core can access these memories using the addresses that start with 0x00xx xxxx. These are referred to as Local L2 or Local L1D addresses.

    Other bus masters in the C6747, like the PRUSS and the EDMA3, can access these memories only from the outside using the Global addresses which start with 0x11xx xxxx. Both addresses reach the same physical memory cells, but only the DSP instructions can access the Local address ranges.

    The DSP can also use the 0x11xx xxxx Global addresses with no performance penalty or any negative effect. The only reason not to use the Global addresses exclusively is that some boot modes may be hardcoded to start running at 0x00xx xxxx. This may not be an issue in your application, but just something to be aware of. In all other cases that I can think of, the Global address is the best choice to avoid any later confusion.

    Regards,

    RandyP

    So apparently this is the answer...the uPP has a DMA which is not part of the DSP core, so it can address the L1 and L2 memory only through the "global" address.

    Titusrathinaraj or someone else, can you confirm that this is the case?  (It would be nice to have it documented by someone from Texas Instruments.)

    Also, are the TI people sure that there is no performance penalty by using the "global" address, and that it will not affect the caching processes?

    Regards,

    Michael

  • 0 in reply to Michael Greenspan
    TI__Guru* 83825 points

    Hi Michael 

    So apparently this is the answer...the uPP has a DMA which is not part of the DSP core, so it can address the L1 and L2 memory only through the "global" address.Titusrathinaraj or someone else, can you confirm that this is the case?  (It would be nice to have it documented by someone from Texas Instruments.)

    [MB] Yes, all master peripherals (upp, VPIF, USB, EDMA, EMAC etc) can see the L1D and L2 memories at the global address only. 0x11xyz. 

    This is also (although not explicitly) conveyed via Table 3-4 in the datasheet which shows the memory map from an SoC perspective. 

    Also, are the TI people sure that there is no performance penalty by using the "global" address, and that it will not affect the caching processes?

    [MB] Yes, there is no performance penalty. This is simply address translation, and internally the master peripherals see the DSP memory at this address. 

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    Intellectual 575 points
    Thanks Mukul...now I see ... in Table 3-4 there are 4 columns, and in white, the part of the memory map that is visible to that part of the SoC. and that term "master peripheral" means one of those peripherals which you listed which can be a bus master.