• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1424 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.

TM4C123GH6PM: Incorrect Oscillator settings? (external clock)

James Lawson77
Prodigy 50 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: EK-TM4C123GXL

This is a custom board where a 16MHz clock is supplied from an FPGA into  OSC0 (pin 40) of the TM4C123GH6PM and OSC1 (pin 41) has been disconnected.  I was attempting to get the JTAG working on this board using the XDS100V2.  I performed the JTAG verification command built into CSS which ran successfully (and still runs successfully).  I then went into debug mode on a project that I had for the EK-TM4C123GXL development board just to test the programming (the project would not do anything useful or visible on this new board).  Going into debug mode appeared to work fine I then pressed pause whereupon I was informed that the debugger did not know what point in the execution the code was.  From this point on I have been unable to flash the TM4C123GH6PM , I presume on the first occasion I successfully flashed something that broke the JTAG communications.  I think this may have been the oscillator setting?

/*****************Setup clock**************************/
//Set the system clock to 80 MHz
SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

If so what would be the correct SysCtlClockSet()?

I'm going to have to do a lot more blue wire work to get a reset button on this board...

Thanks,

James.

  • 0
    Guru 27665 points

    This is what I use

     	/* Set up clock (80MHz with 16MHz crystal.) 200MHz PLL/2.5 */
    SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | 
    	SYSCTL_XTAL_16MHZ);

    Looks the same to me. We did start with a crystal but change to an oscillator input. You might check that you are not overdriving the input.

    What else do you do in or program besides set the clock?

    James Lawson77 said:
    I'm going to have to do a lot more blue wire work to get a reset button on this board...

    Should be available on the JTAG connection should it not?

    Robert

  • 0
    TI__Guru*** 135355 points
    Hello James,

    First off to possibly save you work on the reset button, please see this thread: e2e.ti.com/.../310876

    As far as your System Clock setup, that clock setting used seems to be fine. I tested on our TM4C LaunchPad that it works without issue.

    Given your description of your hardware, how good is the integrity of that 16MHz signal? It looks like the duty cycle only needs to be within 45-55%, so if you have it setup for a 50% duty cycle you should be well within that tolerance, but it's worth checking I think.
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Might it be that the FPGA's 16MHz signal, "arrives too early - or too late" - since the MCU has no control over signal arrival?
    Firm/I have done similar - via FPGA & CPLD - short/direct HF lead lengths - and absence of other (nearby) switching signals - always help.

    As always - does this situation evidence across multiple boards? (even those to be "already programmed" - and/or using "known good"     (i.e. SAFE, simple, vendor example programs?)

    One more point - perhaps critical (and thus far silent) our "MCU & FPGA Apps" (usually) employ the MCU to configure the FPGA.     Unless you (first) employ the MCU's PIOSC - then "switch over" - how do you (then) configure the FPGA?    (without the MCU's vital assistance to the FPGA...)

  • 0 in reply to Ralph Jacobi
    Prodigy 50 points

    I have tried the LMflash utility unlock (which requires a reset button, that I have added) and it fails.  Does this suggest there is a problem with my JTAG connection? (despite the verify function saying everything is fine).  The FPGA is an Intel MAX10 so loads its bitstream very quickly from internal flash.  The clock is generated by division of a 48MHz oscilator and is 50% duty cycle.  This is a one off development prototype so I don't have spare boards to try.

  • 0 in reply to James Lawson77
    Prodigy 50 points
    I have now managed to get debugging working. The problem turned out to be that the 16MHz FPGA clock was not present anymore on my board because when I had initialy programed the FPGA I had not written to its internal memory only programed it via JTAG so at the next power on it did not generate the clock. I have now programed the internal memory (done by selcting the .pof file rather than .sof file).

    However even with this clock present I could not get the LMflash unlock to work (although it does not matter anymore as I can debug the device normaly).
  • 0 in reply to James Lawson77
    Guru 117855 points

    The description of that FPGA would have saved "helper" time/effort.
    Glad you persisted & succeeded.

    I'd note that (even) "one off" developments (often) benefit from "multiple boards present!"     (enables the confidence building, "A vs. B vs. C" comparison tests...)     Even one-offs - especially one-offs - benefit from such (added) board/component insights.