• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 500 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Differences Simulating PLL and downloading and debugging on Stellaris Launchpad

joseph schmitt
Prodigy 30 points

Hi 

Im using a Stellaris Launchpad LM4f120XL (now Tiva c), eval kit and trying to configure the PLL

when simulating the code in IAR using the built in simulator it runs perfectly however when i download it to the board and attempt to run the code, stepping through reveals some interesting behaviour

in the simulator the value 2048 (0x800) is OR'd with 0x80000000 to produce the value seen in R0 the program then proceeds to execute the next instruction as expected

however..

when connected to the launchpad

it adds this strange number to register R0 (which appears to be a combination of the two instruction addresses, then moves the program execution to the location shown below (which subsequently causes the program to stall and become unresponsive)

any ideas whats going on??

the register under consideration is the RCC2 register (0x400FE070)

Thanks

  • 0
    TI__Genius 10040 points

    When using the simulator, code sequences such as the one you have provided would have no impact on the operation, since the simulator does not use the PLL or any of the hardware specific clock configuration to control how it operates.

    However, on the real device, the code sequence that you provided could have some unexpected impact to the debugger connectivity.

    SYSCTL_RCC2_R = 0x80000000;
    SYSCTL_RCC2_R |= 0x00000800;

    The first statement enables the use of the RCC2 register, but changes most of the clock configuration values from their defaults (0x07C06810).  This will enable the PLL, change the default divisor values, and switch from the PIOSC to the external oscillator/crystal.  All of these changes together will likely impact the JTAG interaface, resulting in potentially erroneous debugger operation.

    I would recommend that instead of writing your own clock configuration sequence, that you use the SysCtlClockSet API, which has been written to handle the various clock configuration changes with the appropriate delays put in place to allow the clock sources to stabilize before returning control the main functions.  Also, if you are needing to step through your startup code, I would recommend that you not step through the clock setup code, but step over it, allowing it to run to completion, without debugger access potentially getting interrupted.

    --Bobby