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

How to enable ducati unicache on DM8168?

Prabhu Sivaraja
Prodigy 210 points
Other Parts Discussed in Thread: SYSBIOS

Hi, 

I in the process of enabling the unicache that is shared by the video and display M3s on DM8168. Once I enable cache I am unable to load code as my code hangs in the enable cache routine before it hits main. So I am not sure whether I am missing step in enabling a cache or whether I am doing something else wrong. 

Note:

  • I do not use syslink so can't use any syslink libraries to initialize and manage cache. 
  • I don't use CCS to compile my code but rather just makefiles along with the .cfg and .bld files. 
  • I only enable ducati unicache and NOT the ducati MMU.

 

Here is what I am doing to enable cache

  • Added the following in my .cfg file 
    • xdc.useModule('ti.sysbios.hal.Cache');
    • var Cache = xdc.useModule('ti.sysbios.hal.unicache.Cache');
    • Cache.enableCache = true;
  • Explicitly used functions Cache_inv(...) and Cache_wbInv(...) in my code whenever necessary. 
When I load this code using CCS, it hangs before it even hits main(). See screen shot of where its hanging. Not sure what's going on here. 
My questions:
  • I am missing a step in enabling cache? 
  • From the screen shot can you tell why the code is hanging?  
  • I just need cache and do not need the MMU. That's why I did not enable or configure the MMU. This is possible correct? 
Thanks in advance. 
  • 0
    Prodigy 210 points

    I did more experimenting. I did NOT turn cache on in my .cfg file but still left the Cache_inv routines in my code. This time I was able to load my code and step through it but got stuck at the same place as pictured above when I tried to execute cache_inv(). So I knew I was missing something that the cache routines needed. After more digging(thanks to another post on e2e) I found out that it was because the gates protecting access to the unicache registers shared by the two M3s need to be initialized. So as per the post I found, I added the following to my .cfg file. 

     

    var GateDualCore = xdc.useModule('ti.sysbios.family.arm.ducati.GateDualCore');

    GateDualCore.initGates = true;

    This seems to solve the gates not being initialized issue. Now with cache turned OFF the cache_inv() routines do NOT get stuck and everything works fine.

    But as soon as turn cache on I get the following CPU error while trying to load code through CCS. 
    Error 0x00000020/-1311
    Error during: Execution, 
    CPU stall due to LOAD/STORE detected...attempting recovery...     
    Stall recovery and target halt were applied successfully!         
    Reccommendation: Normal use of the debugger can resume.
    So in summary, I know why I am getting stuck in my first post. I've gotten past that by initializing the gates it seems. But now I have this CPU error. Seems like I am still missing a step. 
    Please let me know if you see anything obvious that I am missing. Still not sure whether I can just turn on cache without the MMU. 

    Also not sure whether initializing the gates like this would be the final solution. Currently I only have vpss M3 out of reset but eventually I want both M3s to be active. In the case of both M3s being active, do I just do this one core and always bring that core out of reset first?  

     

  • 0 in reply to Prabhu Sivaraja
    TI__Mastermind 30830 points

    1) When the unicache is enabled, there has to be an AMMU table entry for every ducati CPU access below address 0xe0000000. Otherwise you'll get a page fault exception.

    2) The GateDualCore module will get configured automatically if you set the Core.id of your respective ducati core applications accordingly:

        var Core = xdc.useModule('ti.sysbios.family.arm.ducati.Core');

        Core.id = 0;   /* for the application running on Core 0 */

    and

        Core.id = 1;   /* for the application running on Core 1 */

    2) The CDOC for the ti.sysbios.family.arm.ducati package:

        http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_33_00_19/exports/bios_6_33_00_19/docs/cdoc/ti/sysbios/family/arm/ducati/package.html

    describes some of the details of configuring a ducati application.

    I'll provide more details in a follow on post.

    Alan

  • 0 in reply to Alan DeMars
    Prodigy 210 points

    Thanks Alan....Adding AMMU table entries seems to do the trick and now I can run my application without any issues. 

    Your link was helpful too. 

    • I do set the core id in each of my applications. But do I just initialize the gate and set the mmu in core 0 only? I am thinking I just need to do this once either in core 0 or 1.
    • Is there a document/wikipage that sheds some light on the ducati ammu. 

    - Prabhu

  • 0 in reply to Prabhu Sivaraja
    TI__Mastermind 30830 points

    Prabhu,

    I'm glad you are up an running!

    1) You should not have to manually initialize the gate nor the mmu within your application. By default this will be done automatically by Core 0. By convention and design, the two code images should be loaded into the ducati memory. Then core 0 is allowed to run, following by core 1. Core 0 will initialize all the shared resources prior to Core 1 attempting to use them.

    2) Section 7.4 of the TRM (link below) describes the AMMU.

        http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vX.zip

    Alan

  • 0 in reply to Alan DeMars
    Prodigy 210 points

    Thanks again...

    -  I guess I still need to configure the MMU if I want only specific regions cached. Thinking more about my specific situation, It seems like I need to do this so I'll still explicitly configure MMU during Core 0 bring up.