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.

F28M35 RevB not booting up

Other Parts Discussed in Thread: CONTROLSUITE

I've been working with the F28M35H52C1 Rev0 for a while, and it has been working fine generally. However, we just got RevB silicon, and the M3 core no longer boots up from the debugger. After resetting each core and then resuming the cores, the M3 hangs "In Reset".

Nothing has been changed on the hardware or software since switching to the RevB. Any help is appreciated.

  • Michael,

    what are the boot mode pins set to? Please refer to the latest data sheet from web for the updated boot mode table 3-18. I believe the table in TRM is yet to be updated.

    Also can you try using the latest controlSuite release for MWARE (the IPCMtoCBootControlSystem()  in ipc_util.c) is updated to work properly for REVB, I don't think this is the issue you are facing though.

     

    Best Regards

    Santosh

  • All the dip-switches on the controlcard are down (towards the label "BOOT"), in the same position as my Rev0 board.

    The debugger cannot read registers from the M3. Does reading the GPIO registers on the C28 work?

    If so, then 34 and 43 are 0, 35 and 47 are 1. This corresponds to Boot to OTP, which is not what I want.


    I'm confused however, since this conflicts with the dip switches, which would suggest all pins should be pulled up. That corresponds to the Boot to Master Subsystem Flash Memory on the Rev0 board, which makes sense.

  • As I understand you are able to connect to C28x but not M3 - right?

    There are lot of differences of between F28M35x REV0 and F28M35x REVA. Some of them could be needing emulation driver fixes, did you try with the latest CCS (v 5.5x)? This would be the first thing I would try. Are you using onboard FTDI(XDS100v2) for JTAG or you are using any external emulator?

    Also, Boot mode 6 on REV0 defaults to Flash, but on REVA this would make the device boot to OTP. It is possible to read the pin status from either core on the REVA, however the M3 should have set the GPIODEN for the needed IOs before.

     Try setting the boot mode switches to ALL LOW (I guess the control card is shipped, with all boot mode pins set to ALL HIGH) so flip them other side, power off and on the board and try again?

     

    Best Regards

    Santosh Athuru

  • Hi Santosh,

    Yes, I the C28 boots up but the M3 stays "In Reset"

    I am using CCS 5.5 already, and using the onboard JTAG.

    I've noticed a couple more points:

    The board is connected to our own PCB via the DIMM 100 slot. It only does not boot up when connected to our board! If I have the board isolated, and power it with USB, then the M3 does boot up! Looking at the DIMM100, I see pins 34 and 43 brought out. Are those the only ways an external board might mess up the boot? Our external board should not be touching those pins, but I will investigate.


    The other observation is that even when connected to our external board, the M3 boots up when I power cycle. It doesn't work if I try to run with the debugger. Does that give any insight?

  • Was the controlCARD updated at all going from Rev0 to RevB? Are the pinouts any different on the DIMM100? I have Revision G of the controlCard schematic. That's the latest in controlSuite. Is there any new one?

  • Michael,

    the control card remained same, the device pin-out didn't change between REVs. 

    Now, when you connect the control card to your baord, looks like the device boot mode pins are set to Boot-TO-OTP, this boot mode defaulted to boot-to-Flash on REV0, but on TMS version of this Si this would boot to OTP and when OTP is not programmed the device would go into reset (fetching 0xFFFFFFFFF from OTP).

    so M3 would be going into these reset loops and depending on when you connect to target from CCS you might be able to connect or you might not be (if CPU is under reset or if it is being initialized by boot ROM at that instant). But once you connect, you would usually do a debug reset and load code to flash and run from flash, you aren't running boot ROM any more so the same reset loop won;t happen any more and you wont see this error.

    check your board and if you re booting to flash, then pull all the boot mode pins HIGH.

    Hope this helps.

    Best Regards

    Santosh Athuru

  • All of the boot pin dip-switches were already pulled to high. However, I noticed that pin 43 was still low. I probed and resistors 312 and 313 on the controlCard were open. I could clearly measure +3V on the side of the resistor connected to +3V, but on the other side of the resistor I measured 0V. Resistors 314 and 315 worked properly and pulled up pins 35 and 34, but not 312 and 313.


    I pulled out a new controlCard out of the packaging and probed. Resistor 312 on this one was still broken, but 313 was working. So on this fresh controlCard, pin 43 was not being pulled up either.

    What confuses me is why the debugging works when I do it with the controlCard isolated. Maybe it is tri-stated but pulled low on the external board?

  • Hi Santosh,


    I figured out the issue. On the controlCard, pins 43 and 47 are being used for ethernet purposes, and so are actually NOT pulled up but pulled down. I don't understand why it was done this way, but those pins are 0. This happened to still work, because 1,1,0,0 (row 12) on the boot table still defaults to boot-to-flash.

    Then, our external board pulled down pin 34, which changed it to row 4 on the boot table.

    So we will fix that on our external board. This will work for our purposes.

    The only remaining question for TI is then why pins 43 and 47 are used in this way on the controlCard? It is confusing since people may assume that the pins are pulled one way by the dip-switches, but see unexpected behavior like this.

    Thanks for your help!

  • Michael,

    I hear you...thanks for the feed back, we should probably add it to the documentation. I will ping the guys.

    on M35x REVA, there is an option for users to go choose different boot mode pins if the factory default ones doesn't fit the design. Refer to the below forum post to know how to do this.

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/312626.aspx?pi303962=1

     

    Best Regards

    Santosh Athuru