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.

CLK_PRD Always Placed at Hard Address



We are upgrading one of our products from a F2812 to a F28335 processor, both running DSP/BIOS 5.41.

I have noticed that each has the same global symbols listed in the map file at identical physical addresses.

0000bb7f CLK_PRD
0000bb7f _CLK_PRD
0000bb80 CLK_COUNTSPMS
0000bb80 CLK_HTIMEPERLTIME
0000bb80 GBL_CLKIN
0000bb80 _CLK_COUNTSPMS

This is not a problem in the F2812 as this range of addresses is reserved and not used by our code, but in the F28335 this is located in L3 SARAM, which is being used.

I have tried various settings in DSP/BIOS to move them and they always exist where they are.

Can anyone explain what is happening?  Is this normal behavior?

Thanks,

Mark

  • Mark,

    This is expected.  These particular symbols are constant values, not target addresses.  (For example, a GBL_CLKIN of 0xBB80 corresponds to 48000KHz.)  The listing in the map file says “address” for the column, which it is for most symbols, but for constants it is the “value”.  This isn’t obvious and can be confusing.    

    Scott

  • Scott,

    Thanks for the info.  That puts us at ease.

    Can you direct me to some documentation that covers this?

    Thanks,

    Mark

  • Mark,

    I’ve not seen any documentation that says how constant values are represented in the map file.  I’ve just observed how they are represented by looking at map files.

    If you’re asking about these particular constants, they are determined based upon the CLK configuration parameters at build, and represent:

    CLK_PRD and _CLK_PRD: The timer period register value for generating the configured tick rate.

    CLK_COUNTSPMS and _CLK_COUNTSPMS: The timer counts per millisecond.

    CLK_HTIMEPERLTIME: High resolution counts versus low res counts.

    GBL_CLKIN: Input clock frequency in KHz.

    Scott

  • Thanks Scott.

    Yes, all of the constant values make sense based on our settings.

    Thanks for the help!!

    Mark