DM648 DSP BIOS Timer setup

All of the BIOS functions return values that are calculated based on the information you provide to the configuration file (e.g. DSP speed). You can watch the value of the timer configuration change based on these values assuming you have not manually input the timer configuration.

Check out Scheduling->CLK - Clock Manager->Properties. You should see a checkbox to "Directly configure on-chip timer registers" and, if unchecked, the greyed out configuration values below will be automatically populated. If this box is checked the values are input manually.  Is this value input correctly?

The API should definitely not be using CLKOUT as the baseline for its calculations, but if something is in fact misconfigured this could explain why you see the incorrect timing numbers.

Hi Tim,

well... on my board its not like that - it seems that the API uses CLKOUT. My settings are:
CLKOUT is 693MHz
CLK -> Input frequency manually set to 115.5
CLK -> PRD manually set to 115500
with that, the timer ticks with 1ms.

still the Bios API returns wrong values:
CLK_countspms == 693000 (should be 115500)
CLK_cpuCyclesPerHtime == 1 (should be 6)
CLK_cpuCyclesPerLtime == 115500 (should be 693000)
CLK_getprd == 693000 (should be 115500)

The default BIOS configurator setting (Specify input clock deselected, directly configure PRD deselected, 1000 microsec/tick) results in 6ms/tick and
CLK_countspms == 693000 (should be 115500)
CLK_cpuCyclesPerHtime == 1 (should be 6)
CLK_cpuCyclesPerLtime == 693000 (correct value but not true due to 6ms/tick)
CLK_getprd == 693000 (should be 115500)

its not a big problem... just a /6 that is required in the time-calculations - but it makes this part of the code different on DM642/648. I was just wondering why its required since I wanted to have as much identical code on DM642/648 as possible...

At the moment I use BIOS 5.31.0. I'll try with the lates version that is available for download - 5.33.06.

bye,

Thomas

its the same with Bios 5.33.06

and finally...: on the DM642 everything is correct.

CLKOUT is 600MHz
CLK settings are default, 1000 microsec/tick, directly configure PRD deselected. according to spru582, Clock/8 is used for the timer.

results:
CLK_countspms == 75000 - correct
GBL_getFrequency == 600000 - correct
CLK_cpuCyclesPerHtime == 8 - correct
CLK_cpuCyclesPerLtime == 600000 - correct
CLK_getprd == 75000 - correct

Thomas,

Thanks for investigating this. Can you check the DM648 to see if the Timer registers are actually getting programmed correctly?

Thomas,

I wrote a simple test case myself and I think this is indeed a bug. I'll check with the BIOS folks and let you know what I find out.

Hi Thomas,

FYI we have confirmed this is a bug and created bug #SDOCM00060862 to track it.

Hi Tim,

thanks for your fast reply...

Thomas

Hi Tim...

There is another strange timer-setup-behaviour after switching to BIOS 5.33.06. I did not see this yesterday - until I powercycled the DSP. It seems that in my mini-app, DSP BIOS 5.33.06 does not initialize the timer registers. Until the powercycle they were still initialized by the last run with 5.31.02.

When I press the reset button on the EVM648 or powercycle it, the timer registers are reset:
EMUMGT_CLKSPD: 0x0006000
PRD12: 0x00000000
TCR: 0x00000000
TGCR: 0x00000000

Normally DSP-BIOS seems to initialize the timer registers after main() is left and before the first user task starts. Using BIOS 5.33.06 this is not done - the timer register remain uninitialized. Using BIOS 5.31.02 the registers are initialized before my first task is executed:
EMUMGT_CLKSPD: 0x0006001
PRD12: 0x0001c32c
TCR: 0x00000090
TGCR: 0x00000007

The PSC module status for the timer is identical for both versions, MDSTAT11 is 0x00001E03 directly after reset.

With BIOS 5.33.06 there is a linker warning that was not there before:
[Linking...] "D:\Programme\Texas Instruments\C6000 Code Generation Tools 6.1.10\bin\cl6x" -@"Debug.lkf"
<Linking>
"evm648initcfg.cmd", line 274: warning: symbol "CLK_F_gethtime" from file
   "D:/CCStudio_v3.3/bios_5_33_06/packages/ti/bios/lib/biosDM420.a64P<clk_getht
   ime.o64P>" being redefined

in line 274 of evm648initcfg.cmd there is this:
        CLK_F_gethtime = _CLK_gethtime;

Maybe this is a hint. I have ignored this warning yesterday.

Tim - it seems that you have a EVM648 running on your side. It would be great if you could run your yesterdays example with BIOS 5.33.06 to see if the timer registers are initialized.

I have downloaded BIOS 5.33.06, installed it and selected it in the CCS 3.3 Components manager and rebuilt my app. Is there something else required to switch between BIOS version?

bye,

Thomas

Thomas said:

Tim - it seems that you have a EVM648 running on your side. It would be great if you could run your yesterdays example with BIOS 5.33.06 to see if the timer registers are initialized.

Thomas said:

I have downloaded BIOS 5.33.06, installed it and selected it in the CCS 3.3 Components manager and rebuilt my app. Is there something else required to switch between BIOS version?

Thomas said:

[Linking...] "D:\Programme\Texas Instruments\C6000 Code Generation Tools 6.1.10\bin\cl6x" -@"Debug.lkf"
<Linking>
"evm648initcfg.cmd", line 274: warning: symbol "CLK_F_gethtime" from file
   "D:/CCStudio_v3.3/bios_5_33_06/packages/ti/bios/lib/biosDM420.a64P<clk_getht
   ime.o64P>" being redefined

Thomas,

Can you please make sure that you have rebuilt your configuration file after swapping to v5.33.06? When updating BIOS you need to make sure that the .tcf file gets rebuilt. If you are still having issues after this please send in a test case. I cannot find anyone that has ever seen this issue before, so we'll need a test case to look into it.

Hi Tim,

I've done this:
*) select BIOS version in configuration manager
*) close/open CCS
*) build clean
*) build
*) press reset button on the EVM648, download the mini-app and jump to the first instruction of the first task after main.

selecting 5.33.06 brings both effects described before: the linker warning and the timer registers are not touched. Switching back to 5.31.02, the timer is initialized.

I've removed everything from the project except a main and a user task with one "nop" - still the behaviour is the same. Would you run this mini-testapp if I'd email it to you?

bye,

Thomas

Hi Tim,

I think I found the problem. In the build options there is a Tab DspBiosBuilder with 'specify search directories for .tci files'. There was this path:
$(Install_dir)/bios_5_31_02/packages;

removing this path also removes the problem. Should this setting be automatically changed when a BIOS version is switched?

I use dvsdk 1.10.00.26 and link the libs that are included there, for example pal_sys_bios.lib. Can there be a problem when I use a different BIOS version? Do I have to rebuild the libs before using them in a different BIOS version?

bye,

Thomas

Thomas,

When you install a new version of DSP/BIOS, the build options of your project are not changed automatically unless they are relative to the env variable.

When you install the a newer DSP/BIOS version, the environmental variable (start-> Control Panel-> System, Advanced tad, Environment Variables) below is updated:

BIOS_INSTALL_DIR.

So the build options for your project should not point to a specific version of DSP/BIOS, it should use the variable above instead. If you removed the path ($(Install_dir)/bios_5_31_02/packages;) and it worked, it could be that the newest versions of DSP/BIOS already look for tci files inside "../packages" automatically.

Hope this helps,

Mariana.

Hi Mariana,

thanks... My app builds without the "$(Install_dir)/bios_5_31_02/packages" setting - so I'll keep it deleted.

When switching between BIOS version, do I have to rebuild the libs I use out of the pspdrivers directory? At the moment I link the binaries that are there - for example pal_sys_bios.lib. Can there be problems if I link for example pal_sys_bios.lib (maybe built with 5.31.08) to my application that is built using BIOS 5.33.06?

bye,

Thomas

Good catch Thomas,

As Mariana said there is a Windows Environment Variable that is updated when a new version of BIOS is installed. There's no way the BIOS installer could know which projects are hard-coded to point to another directory. You could add the environment variable to the DSP/BIOS Builder (I think the syntax is %BIOS_INSTALL_DIR%) so as to make the project more dynamic.

Thomas said:

I use dvsdk 1.10.00.26 and link the libs that are included there, for example pal_sys_bios.lib. Can there be a problem when I use a different BIOS version? Do I have to rebuild the libs before using them in a different BIOS version?