• State Answer Suggested
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 575 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28069: Flash2806x_ToggleTest API produces wrong toggle speed

Gunter Schmer
Genius 13637 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: MOTORWARE

Hi,

a customer is trying to get to the bottom of why in their case the Flash2806x_ToggleTest does not produce the desired 10kHz toggle rate. In fact the customer reports in the order of 1.35MHz, so >100x the speed.

Here are the assumptions:

[] The Flash2806x_ToggleTest ROM entry point is 0x003FFE7 (is this correct)

[] Device_cal is being called at 0x003D7C80

[] CPU_RATE is 12.500L

[] The SCALE_FACTOR is being generated using the unmodified header Flash2806x_API_Config.h

[] Flash_CPUScaleFactor@0xD02 and Flash_CallbackPtr@0xD04 are being set within an EALLOW/EDIS frame.

[] The PLL is tuned to align with the frequency specified in this header (80MHz with PLLCR=16 and DIVSEL=2).

[] The indication that the PLL is correct is: The CAN bus is able to operate off the specified frequency (BRPREG = 4, TSEG1REG=4, TSEG2REG=1, SJWREG=0) indicating it’s at the expected rate.

Are we missing any other parameters for the 10kHz desired speed?

Are the entry points potentially wrong?

Here are the entry points in use

abs   003d7c80  _Device_cal

abs   003ffe7  _Flash2806x_ToggleTest

abs   003ffef3  _Flash2806x_APIVersionHex

Is there anything else to consider to achieve 10kHz toggling rate?

Thanks,

--Gunter

  • 0
    Prodigy 80 points

    The lines from the map file were transcribed from a separate computer.  The address of the _Flash2806x_ToggleTest function is "0x003ffee7", 8 hexadecimal characters long.

  • 0 in reply to Carl Kelso
    TI__Genius 13637 points
    Hi,

    do you have an update on the toggle_test issue?

    Thanks,
    --Gunter
  • 0
    TI__Guru 55700 points

    Gunter,


    Yes, your entry point for Flash2806x_ToggleTest is good. From your post, all your assumptions look good as well. Did you check XCLKOUT? Also, I believe you are running the toggle test in your application code. Can you try toggle test using CCS Flash API plugin? Also, does your application code exercise the GPIO which is being used for GPIO Toggle test?


    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 80 points
    Where can I find the CCS Flash API Plugin? Is this an independent download from motorware/CCS?
    Is it available for CCS 6.1.3? It is not referenced in any of the "other useful links" mentioned above, nor have I found reference to it in the documents here: www.ti.com/.../technicaldocuments

    I do not have direct access to xclkout because the pin is overloaded on our schematic. I've been relying on the fact I can receive CAN messages successfully to indicate that the core clock frequency is at least predictable. Is there reason to believe this test is inadequate?

    The system clock is running at 90MHz or 80MHz depending on my test, which is at or near the maximum frequency the system is able to operate at. It would not be possible for me to increase this by the 150x or 135x needed to raise the 10khz toggle test to the 1.5MHz or 1.35MHz I've been measuring. This seems to indicate the clock source cannot be the only source of an issue.

    I have several test pins to choose from, and I have confirmed the toggle_test frequencies described on multiple of them. They are configured as GPIO outputs, and have no other use in the code. The output oscillation predictably moves based on the selected IO line, which confirms I'm at least providing the right toggle register and mask reference.

    My primary suspicion is that if the toggle_test function insertion point is correct, that the scale factor value is not being set correctly. I have confirmed the calculations in the debugger in memory align with my expectations.
  • 0 in reply to Carl Kelso
    Prodigy 80 points
    I think I've root caused the issue.

    The TRM incorrectly specifies the address of the registers and callbacks.
    spruh18f p.202 states:
    FLASH_CPUScaleFactor is at 0xD02
    FLASH_CallbackPtr is at 0xD04.

    The Flash2806x API Readme page 20 says the CallbackPtr is at 0xD02.

    Switching their locations corrects the original problem (I now have the output pin toggling at a 100.3us period, ~10Khz).

    A second concern, according to the Flash2806x API Readme, the flash library is built with AMODE = 1. If this is the case, address 0x3FFDA3 which loads DP with 0x34 will not result in a reference to 0xD00. It instead results in a 7 bit addressing mode, which means the device attempts to read FLASH_CPUScaleFactor from 0x1A04 instead of 0xD04. Using AMODE = 0 when calling toggle test resolves a second set of problems arising from this configuration.
  • 0 in reply to Carl Kelso
    TI__Guru 55700 points
    Gunter,

    I confirmed Carl's observation. As Carl mentioned, Table PIE Vector SARAM Locations Used by the Boot ROM is incorrect. I have already filed a litbug to fix this issue. Please make sure have these variables assigned to below address locations.

    0xD02 - FLASH_CPUScaleFactor
    0xD04 - FLASH_CallbackPtr

    Regards,
    Manoj
  • 0 in reply to Carl Kelso
    TI__Guru 55700 points
    Carl,

    Regarding your second concern...

    1) How did you change AMODE?
    2) Did you make sure to select in CCS Build -> C2000 Compiler -> Processor Build
    Large Memory model
    Unified memory model

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Prodigy 80 points

    I'm using a makefile build.  The build flags include -v28, but not -m20 (AMODE=0 per spru430f p.83).

    I confirmed AMODE was set to 0 in the debugger.

    To configure AMODE=1 before executing the toggle test I used the following:

    asm volatile (" SETC AMODE\n .lp_amode");
    FLASH_ToggleTest( reg, mask );
    asm volatile (" .c28_amode");

    I also verified the disassembly did not reorder the instructions, stepped in, confirmed AMODE was set for the call, and noted the interpretation of one of the addressing modes changed to reflect the .lp_amode assembler directives. (@0x04 became @@0x04).  A few instructions before this, DP is loaded with 0x34, which translates to 0xD00 in AMODE=0, and 0x1A00 in AMODE=1.  Since 0xD04 is explicitly the coefficient used to toggle, and 0x1A04 is in reserved memory somewhere between CPU to CLA message ram and the USB control registers, and there is no other mechanism in the short toggle test code to access anything around 0xD04, this indicates AMODE should be 0 when entering the function.


    As further support, the test fails to toggle the pin at all if AMODE=1 when entering, but with the address of the scalefactor corrected to 0xD04, the pin is toggling at 9.957KHz (100.3us) when AMODE=0.