Starterware/TMS320C6748: Incorrect implementation of API "CacheEnable"

Shrikrishna B

Part Number: TMS320C6748

Tool/software: Starterware

Hello,

While using C6748 StarterWare version 1.20.04 in our product, we found incorrect implementation of CacheEnable API which configures L1P, L1D and L2 cache configuration.

File: \system_config\c674x\cache.c

Line: 154

Cause: "memCfg" value is not properly used, it should be shifted to get correct value for L1P

Refactoring:

       /* Enable L1P Cache */
        HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1PCFG) =
            (HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1PCFG) &
            ~DSPCACHE_L1PCFG_L1PMODE) | ((memCfg >> ((L1P_MEM_UNIQUE >> 1) * 4)) & DSPCACHE_L1PCFG_L1PMODE);

Line: 166

Cause: "memCfg" value is not properly used, it should be shifted to get correct value for L1D

Refactoring:

      /* Enable L1D Cache */
        HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1DCFG) =
            (HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1DCFG) &
            ~DSPCACHE_L1DCFG_L1DMODE) | ((memCfg >> ((L1D_MEM_UNIQUE >> 1) * 4)) & DSPCACHE_L1DCFG_L1DMODE);

Line: 178

Cause: "memCfg" value is not properly used, it should be shifted to get correct value for L2

Refactoring:

        /* Enable L2 Cache */
        HWREG(SOC_CACHE_0_REGS + DSPCACHE_L2CFG) =
            (HWREG(SOC_CACHE_0_REGS + DSPCACHE_L2CFG) &
            ~DSPCACHE_L2CFG_L2MODE) | ((memCfg >> ((L2_MEM_UNIQUE >> 1) * 4)) & DSPCACHE_L2CFG_L2MODE);

Thanks

Shrikrishna

over 6 years ago

0 Norman Wong over 6 years ago

Guru 26430 points

Looks like your thread has been overlooked by the TI guys. Usually threads related to the OMAP-L13x/C674x/etc get moved to the DSP forum. The problem with CacheEnable() was noted in 2014 reply to a 2012 thread.
e2e.ti.com/.../230523
Version 1.20.04 is the last "standalone" version. There is a newer version buried in the SDK that is apparently totally rewritten and incompatible with previous versions. So it is very unlikely that this bug will ever be fixed. Actually the L1P setting does work because the shift is 0. L1D and L2 will always be set to disabled (0) regardless of the config passed in.

0 Rahul Prabhu over 6 years ago

TI__Guru** 114410 points

Shrikrishna,

If you use the macros that are defined in dspcache.h then you don`t need to manipulate the memcfg value inside that function.

for example if you use
CacheEnable(L1PCFG_L1PMODE_32K)

the macro is defined as :
#define L1DCFG_L1DMODE_16K (0x3 << ((L1D_MEM_UNIQUE >> 1) * 4))

so the code will correctly configure the L1P to 32K cache.

Those cache APIs are meant to be used using the macros provided in dspcache.h. though the comments and the code could have been written differently to enforce that usage.

Regards,
Rahul

0 Norman Wong over 6 years ago in reply to Rahul Prabhu

Guru 26430 points

I think Shrikrishna is using the macro constants and there is still a couple errors. Within CacheEnable(), the typical form for copying over the memCfg parameter to the apppropriate register is:

HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1DCFG) =
(HWREG(SOC_CACHE_0_REGS + DSPCACHE_L1DCFG) &
~DSPCACHE_L1DCFG_L1DMODE) | (memCfg & DSPCACHE_L1DCFG_L1DMODE);

Essentially the bottom 3 bits of memCfg is copied over to the bottom 3 bits of the register.

The problem is that memCfg contains L1PMODE, L1DMODE and L2MODE values shifted up by 0, 4 and 8 respectively. Shrikrishna's fix is to shift the mode values back down into the bottom 3 bits before the copy to the register. Works for L1P because the the shift is 0. For L1D and L2, the the bottom 3 bits of memCfg is erroneusly copied over. The bottom 3 bits of memCfg happen to be the desired L1P setting.

0 Rahul Prabhu over 6 years ago in reply to Norman Wong

TI__Guru** 114410 points

Agreed. I reviewed the Macros and do see the point that you are highlighting. Unfortunately starterware software is in maintenance mode so I will document this in the Starterware documentation but we may not be able to provide an updated release.

Regards,
Rahul

0 Shrikrishna B over 6 years ago in reply to Rahul Prabhu

Prodigy 170 points

Thanks Rahul and Norman. Agreed that there will be no update on Starterware. So I will be having customer modifications in my Starterware repository.
One question I would like to ask is what is alternative for StarterWare?

Thanks,
Shrikrishna

0 Rahul Prabhu over 6 years ago in reply to Shrikrishna B

TI__Guru** 114410 points

Shrikrishna,

We plan to do a software refresh for this device by adding support for this device in the Processor SDK RTOS. In that package Starterware will be replaced with register CSL and functional CSL (CSL-FL). This aligns APIs and functions with the newer generation C66x DSP and covers all SOC architectures in the TI ARM and DSP family. We will also add Low level drivers for peripherals that can be used in no-OS as well as TI RTOS.

There are some CSL based examples on the web for this device, if you want to look at the code flow:

processors.wiki.ti.com/.../QuickStartOMAPL1x_rCSL

The Processor SDK RTOS 4.0 release will be available on the web at the end of this month or early July.

Regards,

Rahul

Processors

Processors forum

Starterware/TMS320C6748: Incorrect implementation of API "CacheEnable"