• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 322 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.

DM355 resets when setting ENA in PLLCTL reg of PLLC1 to enable PLL

sandyxb
Prodigy 30 points

writing my own boot loader ... My code follows the procedure from the ARM Ref Guid in section 6.5 for initializing the PLLCs. The code is loaded and controlled through the JTAG interface, running uncached, MMU disabled. It works fine on the DM355 EVM, (a -216 part), but on my board, it causes a hard reset as soon as the write of 1 to the PLLEN bit in PLLC1 happens. This reset occurs by letting the code run, or single step through it, or even break before the store instruction and issuing the write via a debugger through JTAG. I am aware of the wait state and extra divider bits in the MISC register.

Any obvious things I am forgetting?

- setting the DDR PLLC2 before initializing PLLC1? - no mention in ti datasheets

- configuring some debug modes somewhere?

- ARM needs to run cached?

- is a non-locked PLL causing this reset?

Btw, this does not happen in PLLC2.

thx

  • 0
    Intellectual 485 points

    Hi Sandy,

    There is a known issue with PLL1 ENA bit. Go through the DM355 errata section 2.1.1 "Possible Emulator Crash If TCK Frequency Is Greater than MXI Frequency".

    See if it helps.

  • 0 in reply to Snehal Parmar
    Prodigy 30 points

    Thanks,

    I knew about it and am running JTAG at 500khz. , The reset still happens no matter what the JTAG clock.

    I am using the OLIMEX TINY USB to jtag converter with openocd, even built that from the latest sources.

    Any ideas?

  • 0
    TI__Mastermind 41665 points

    If this is happening on one piece of hardware (custom board) and not on another piece of hardware (DM355 EVM) and both are running the same software sequence for initializing the PLL than I would take a look at the potential hardware differences between the two first. In this case since it is setting a PLL bit that is leading to a system reset I would take a close look at the PLL related hardware, namely PLL voltage and oscillator stability, I recall an instance where a voltage was missing or incorrect for the PLL that had a similar sort of failure when trying to enable the PLL (and potentially long term damage to the chip if something was being overdriven).

    You may also want to double check your power up sequence and any configuration or reserved pins to make sure everything aligns with the datasheet and/or EVM, it is possible that something on your board is getting the PLL module into a bad state.

  • 0 in reply to Bernie Thompson TI
    Prodigy 30 points

    Thanks Bernie,

    I plugged the board into a different JTAG emulator and it does not have the reset problem. Turns out openocd does not assert SRST during a TRST, and there were glitches on the JTAG signals. The dm355 thus did not have a proper reset, which caused the board's relatively weak 3.3V rail to collapse as some GPIO to the switcher did not have the right setting, taking the other core voltages down as well, causing the reset.

    A hack to the reset phase of openocd fixed it.

    Thanks,