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.

Slowing down without debuger

Hi all,

I was try to blink an on board LED at 1Hz. The base program is the Blinky_m3 example program provided in the driver package. I used the linker cmd file of MWare\cmd\F28M35H52C1_m3.cmd. I pretty much achieved 1Hz when I run it in CCS debug mode.

It seems that the debuger actually write the program into on-chip flash, because the program can run after reset without connecting a emulator. However, the blinking rate is way lower than 1Hz. Is it possible the PLL setup are different between Jtag mode and standalone mode?

 

thanks a lot,

 

best,

  • Hi Ning,

    please take a look at the last 3 or 4 posts on page 1 of this forum-discussion (http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/148597.aspx) to check if it is the same issue.

    please let us know if the solution suggested by Harrison works for you too.

     

    Best Regards

    santosh

  • Hi Santosh,

    Yes, it is exactly the same problem. I'll try it later today and let you know the result. I'm using a some other target board other than Concerto control card, the boot mode is set by the default on-chip pull-up resistor, from the data sheet, the default boot mode should be from flash.  I tried to power off the board completely, which can rule out the possibility of running from RAM after power on reset, and the led was blinking but with a lower rate, around 7 times lower. 

    A separate but related question:

    Could you help me confirm the following command can set the M3 at 75M and C28 at 150M with a  16M crystal?

        // Sets up PLL, M3 running at 75MHz and C28 running at 150MHz using a 16M crystal
        SysCtlClockConfigSet(SYSCTL_USE_PLL | (SYSCTL_SPLLFMULT_M & 0x300) | ( SYSCTL_SPLLIMULT_M & 0x12) |  SYSCTL_SYSDIV_1 | SYSCTL_M3SSDIV_2);

    According to my calculation, the multiplier should be 18.75 in order to get Fout at 300M, by setting the M3 divider to 2, the M3 should be at 75M.

    The reason for asking this is the program should  toggle the LED at 1Hz, with 50% duty cycle, but the result is not that accurate. It only blinked 24 times in a 30sec interval.

    The way I tried is using SysCtlDelay(12500000) to consume 37.5M CPU cycles, a half of CPU cycles per second, between LED toggles. It seems that the problem happened either the wrong PLL setting or the miscalculated delay cycles.

    Thanks a lot for your quick reply.

     

    best,

    Ning

     

  • Hi Ning,

    The SysCtlClockConfigSet() configuration you posted will give you an effective PLL multiplier of 18.75.

    The timing issue you are seeing is likely caused by the SysCtlDelay() function.  There is a bug in the SysCtlDelay() function where the delay may take a different amount of cycles depending on how the instructions are aligned in memory.  The correct function is provided below.  This will be fixed in the next release of the device support files.

    In MWare/driverlib/sysctl.c, replace the existing SysCtlDelay assembly function with:

    //*****************************************************************************
    //! Provides a small delay.
    //!
    //! \param ulCount is the number of delay loop iterations to perform.
    //!
    //! This function provides a means of generating a constant length delay. It
    //! is written in assembly to keep the delay consistent across tool chains,
    //! avoiding the need to tune the delay based on the tool chain in use.
    //!
    //! The loop takes 3 cycles/loop when residing in flash and 4 cycles/loop
    //! when residing in RAM.
    //!
    //! \return None.
    //*****************************************************************************
    __asm(" .sect \".text:SysCtlDelay\"\n"
    " .clink\n"
    " .thumbfunc SysCtlDelay\n"
    " .thumb\n"
    " .align 4\n"
    " .global SysCtlDelay\n"
    "SysCtlDelay:\n"
    " subs r0, #1\n"
    " bne.n SysCtlDelay\n"
    " bx lr\n");
    Regards,
    Harrison 
  • Hello Harrison!

    I use SysCtlDelay() of v110 programmed into the flash and on my concerto device the delay is 4 cycles instead of 3.

    The dissassembly:

              SysCtlDelay:
    0020d534:   1E40     SUB             R0, R0, #0x1
    0020d536:   D1FD     BNE             SysCtlDelay
    0020d538:   4770     BX              R14

    The code is aligned to 4, the M3 runs on 60MHz with 1 waitstate (FlashInit() is called).

      // Sets up PLL, M3 running at 60MHz, C28 running at 60MHz, GPIO34-XPLLCLKOUT running at 60MHz
      // 20MHz * 6 = 120MHz; Clocks divides by 2 -> 60MHz for all                      
      SysCtlClockConfigSet(  SYSCTL_USE_PLL             // PLL is enabled
                           | (SYSCTL_SPLLIMULT_M & 0x6) // Multiplier=6         (20MHz*6  = 120MHz)
                           | SYSCTL_SYSDIV_1            // PLLSYS and C28 Clock (120MHz/2 =  60MHz)
                           | SYSCTL_M3SSDIV_1           // M3                   (60MHz /1 =  60MHz)
                           | SYSCTL_XCLKDIV_1           // XPLLCLKOUT           (60MHz /1 =  60MHz)
                          );

    What other may have an influence?