• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 85 subscribers
  • Views 1080 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.

Concerto Reset Pins

Joel Clasquin
Intellectual 700 points

Hi,

I have created my own board with a Concerto processor.  The reset circuit I'm using is the same as the DIMM 100 example.  I have 2.21K pull-up resistors and 0.1uF caps tied to the /XRS and /ARS pins.  

I have tested 10 boards.  Four of them work correctly and I measured 3.3V on the reset pins.  

Six of the boards will not allow me to program them with my XDS510 emulator.  

They will sometimes fail with an error message about being held in reset, and other times they will go through the steps in the GEL file until M3_Ram_Init is called and then they get forever stuck in a while loop.  On these six boards I'm measuring 2.8V on the reset pins.

I can only assume that these pins are acting as outputs for some reason, otherwise they should be getting pulled up to 3.3V.  Right?  

What can cause this?  I can't find documentation about when and why these pins are outputs.

Thanks,
Joel 

  • 0
    Guru 192875 points

    Hi Joel,

    Did you try differentiating the 2 boards(working one and the non-working one) wrt to signals on DSO while programming? 

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Intellectual 700 points

    Hi Gautam,

    Thanks for the reply.

    Are you talking about the JTAG signals during programming?  I looked at the TDI and TDO pins during programming and I don't see a difference between the good and bad boards.

    Thanks,
    Joel 

  • 0 in reply to Gautam Iyer
    Intellectual 700 points

    I was reading your post again and now I understand your question.  

    Looking at the reset signals on the scope, a good board has a flat voltage of about 3.3.  The bad boards have a strange looking waveform.  It looks like the processor is driving the reset line low about once every 1.25 mS, then the line charges up (like a capacitor charge curve) back up to 3.3V before going low again.

    This is why I was seeing about 2.8V on a voltmeter.  

    So my question is what would cause the Concerto to drive the reset line low?


    Thanks

  • 0 in reply to Joel Clasquin
    Intellectual 700 points

    Here's another update.  

    The good boards have a constant 3.3V reset line when they are programmed and running without the emulator.

    When I erase the entire FLASH on both cores, disconnect the emulator and cycle power, the good boards have the same shape waveform on the reset pins.  But the frequency is different.  

    It looks like the processor is pulling the reset lines low every 27.5 ms, which is quite different than the bad boards which reset every 1.25ms.  

  • 0 in reply to Joel Clasquin
    TI__Genius 16260 points

    Hi Joel,

    this could be a symptom of few issues. Important to say that the XRS pin is not an input only; the internal circuit has the ability to drive it low, which justifies the behavior you are seeing.

    The watchdog is one possible cause. Every time the timer expires and the watchdog function forces a reset, the XRS pin will drive low. Also, the M3 core holds the C28 in reset until an IPC command is exchanged. Depending on the configuration of the GEL files, you could have a situation in that XRS is driven low.

    Could you please share more details of your application? What is the IDE you are using, version number, and Concerto device part number? Are you running an example?

     

  • 0 in reply to Joel Clasquin
    Prodigy 210 points

    We also have a custom board using the F28M35 processor (specifically XF28M35H52C1RFPT rev B).  We are seeing the same problem which is preventing us from programming the device for the first time using JTAG.  On the rev 0 silicon we saw the same problem but the level was high enough that it didn't prevent programming.  Once it was programmed the problem went away.

    With this rev B silicon we cannot program.  we have tried forcing WIR mode with no success.  We have tried forcing BOOT FROM PARALLEL GPIO mode which also was not successful.

    Since this is apparently a known problem does TI have a solution.

  • 0 in reply to Russell Parker
    TI__Genius 16260 points

    Russ,

    The first revisions of silicon depended on a special xml file that has already being integrated in the latest CCS version.

    -  Make sure you have the latest CCS5.5.

    - If you are using a XDS510 interface, in the target configuration file (ccxml file), select the checkbox for extended IcePick router support. Disregard if using XDS100.

    - Select the connection properties so EMU0 is low and EMU1 is high.

     

  • 0 in reply to Lenio Cacula
    Prodigy 210 points

    Thanks for the help.  We tried forcing the WIR mode using EMU0 and EMU1 plus selecting the checkbox for extended IcePick router support and that worked.