• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 1231 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.

F28M35 Starting problems

Mathias Meier
Prodigy 140 points
Other Parts Discussed in Thread: UNIFLASH

Hi everyone,

we are currently developing / testing our second testing board.
 We have started with the demo board and orientated us on that for our first own test board. With that everything runs fine and with the new information we collected from it, we created a new board design that should have been the final one.
We changed nothing regarding power supply, networking an so on. It was more to come to the right board form factor than anything else.

However, this time the F28M35 doesn't start the program on flash. We could connect it without any problems with JTAG to the debugger, save a firmware on both CPUs (M3 and C28) and also start the firmware and everything runs fine. But when we try to start the device without the debugger it don't start in about 99% of the tries.

We found one difference in the power consumption. Starting the device via debugger, the device takes about 20% mA. 
The voltages we have measured on the board seems fine and the be the same as with the first testing board.

With the previous testing board we had never such a problem and since the power supply wasn't changed  we are a bit helpless. It seems that the CPU simply not start and is in a waiting state. (We have tested that setting a IO-Port as output and set it high at the very beginning don't work, only when connected via debugger).

We have the only seen 3 or 4 times correct starting without the debugger, but there was nothing changed compared to the hundreds tried when the CPU not started.

Maybe the community has any idea or a hint where we could find the problem.

With best regards

  • 0
    TI__Guru 57255 points

    Hi Mathias,

    Have you checked the status of the F28M35's boot mode pins (GPIO34, 35, 47, 43) during boot time? 
    You should make sure that resistor pull-ups (or pull-downs) are on these pins to ensure that the proper boot sequence is done (boot to flash in your situation).  Please take a look at the device datasheet for more information.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 140 points

    Dear Brett,


    thank you very much for your answer.

    In the mean time we tried several reset sources and looked at the behaviour.  So after starting the CPU via debubbing we could do resets via watchdog and xrs pin. The device startet after that as it should. Removing the debug cable connection after the CPU is running, it is still running normaly. The CPU also respons correct to the watchdog and xrs reset, which means it start as it should.

    When we start the cpu without debugger, it doesn't start it all. Also a reset via xrs pin doesn't change it.
    We can see that the power consumption at xrs state is lower, than in the unkown not startet state und in the normal running state the power consumption is a bit higher than in the unkown state.

    About the boot mode pins: I have to admit i don't know excatly the configuration, as i don't designed the board. But regarding to the TRM, the boot mode pins are checked after a watchdog and also xrs reset. As the CPU runs fine, after these resets,  when it was once startet via debugger this shouldn't be the problem. Please also note in the previous design the CPU had always start fine and regarding the pins for the boot mode, I got the information that nothing was changed. So I would asume that these pins are not the problem.

    Best regards

  • 0 in reply to Mathias Meier
    TI__Mastermind 19810 points

    Mathias,

    can you let us know that the boot mode pins are set to? Each one of them, high/low.

    I think you mentioned this, but can you confirm the below.

    with debugger connected:-

    1.> if you do a reset from the CCS, and just run the device runs through the boot ROM all the way into your application?

    I believe you mentioned it does, so I don;t suspect the boot mode pins, but is the above behavior consistent and always true?

    without debugger connected:-

    when you power up the board, do you see any toggling on XRSn? Can you program a simple GPIO toggle code in application and try?

    Best Regards

    Santosh Athuru

     

  • 0 in reply to Santosh Athuru
    Prodigy 140 points

    Thank you for your answer.

    With the debugger connected:
    The application started every time after a reset. Even when putting then off the debugger, the application starts fine. Only when completely powering off the device and then powering on without the debugger, it doesn’t work.

    At the moment I can not test if the XRSn toggles as I don't have the test board.

    We have found something new that don't match the above experience, but the boot mode pins weren't set at any specific state. The pins used for some other functions after startup. Setting PF2 and PF3 to high, the device start as it should. So yes it has something to with the boot pins, but it is very unclear to me, why with the first test board we created everything has always run fine and with the second test board where noting was changed regarding these pins (with the exception, that some paths on the board are a bit longer now) it doesn't work anymore.
    And so why it works after a reset isn't also clear.

    We have now an other question: We had read about OTP at 0x6800824 for changing boot mode pins in TRM. In Uniflash 3.4.1 there is no field for it and also the data sheet knows nothing about this OTP address. So how could we program this location?

    Thanks for you help.

     

    Best regards

  • 0 in reply to Mathias Meier
    TI__Mastermind 19810 points

    Mathias,
    The TMS version of F28M35xs supports the options to change the boot mode select pins. The boot ROM chapter of the TRM for your device should tell you the address and details that needs to be programmed - section 6.3.1

    Note that you can program the same pin no for all the boot mode pins and boot ROM will read the same pin twice and boot to boot mode 0xF or 0x0. If those two boot modes are sufficient for your application. Just one way to save some pins for application.

    I'm not sure if uniflash is updated for this, but you can have a CONSTANT Data section linked to this location in OTP.

    Below are the OTP usage details that you need to know for F28M35x, we have the TRM update pending on the below information.


    Hope this helps.

    Best Regards

    Santosh Athuru