• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 341 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.

TMS320F28377S: Boot Sequencing

Luke
Expert 3750 points
Part Number: TMS320F28377S
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi team,

I'd like to confirm our understanding of the power up sequence for the F28377S devices working with TPS3703A4330 and TPS3703A4120 supervisors to monitor the VDDIO and VDD voltages on the DSP and reset it via the XRS_N pin if they get out of the recommended operating ranges. Can you confirm if the below is correct?

Specifically during power up, the chip will be confused by external XRS_N assertions that are less than the 10ms slow-edge bound, the 10ms oscillator start up and the 1.5ms boot-mode sampling. Is this because the chip isn't fully up and running yet and doesn't quite know how to interpret and external reset signal?

For the external supervisors, is the only requirement I need to fulfill with respect to XRS_N timing that the external supervisors hold the XRS_N line low for at least ~21.5ms from the start of supply ramp?  i.e. if I waited 1min after the start of the supply ramp onset, it would also work because the chip is now up and knows how to interpret the external input (warm reset).

Thanks,

Luke

  • 0
    TI__Mastermind 36526 points

    Hi,

    Luke said:
    Specifically during power up, the chip will be confused by external XRS_N assertions that are less than the 10ms slow-edge bound

    Where are you seeing this? During power up, XRSn is already held low by device logic. After XRSn is released by the device, any XRSn pulse greater than ~3.2us will cause a warm reset. 

    Luke said:
    For the external supervisors, is the only requirement I need to fulfill with respect to XRS_N timing that the external supervisors hold the XRS_N line low for at least ~21.5ms from the start of supply ramp?  i.e. if I waited 1min after the start of the supply ramp onset, it would also work because the chip is now up and knows how to interpret the external input (warm reset).

    You do not need to hold XRSn low at all, since the device logic already does this. It is safe to hold XRSn low for however long that you would like, the device will do the warm reset when it is released. 

    Best Regards,

    Ben Collier

  • 0 in reply to Benjamin Collier
    TI__Expert 3750 points

    Hi Ben,

    This was assumed from the specs in the datasheet section 6.9.1.4.1 showing the minimum supply ramp rate of 330 V/s. It is my understanding that since the internal POR circuit holds XRS_N low until the supplies fully ramp (10ms being the longest), the oscillator starts up and boot-mode sampling is complete, the external supervisor must wait at least this long to signal. We also found the below recommendation in the HW configuration guide:

    "however, the power on reset’s pulse-width has to be much longer to account for the time required for VDD to reach 1.5 V (to enhance Flash reliability) and the oscillator start-up period of 10 mS (nominal). You may prefer to keep this duration in excess of 100ms to overcome any other related delays"

    So is the 100ms mentioned not the required minimum time that an external XRS_N assertion must be held during POR? We want to make sure that the 200ms solution isn't marginal and we don't get weird behavior on the rare unit in the future.

    Thanks,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 36526 points

    Hi,

    Luke said:
    So is the 100ms mentioned not the required minimum time that an external XRS_N assertion must be held during POR? We want to make sure that the 200ms solution isn't marginal and we don't get weird behavior on the rare unit in the future.

    The benefit of using the supervisor to hold XRSn low for 200ms would be that the F2837x will start executing user code about 1ms after XRSn is released. There is no functional requirement to hold XRSn low during power on. Of course you must never drive XRSn high, it should only be pulled high through a resistor as described in the datasheet. 

    Luke said:
    "however, the power on reset’s pulse-width has to be much longer to account for the time required for VDD to reach 1.5 V (to enhance Flash reliability) and the oscillator start-up period of 10 mS (nominal). You may prefer to keep this duration in excess of 100ms to overcome any other related delays"

    I think this document is referring to the MCU internal circuitry holding the XRSn signal low for a longer time at startup than it would for some watchdog reset after the MCU has already been powered on. I interpret the last sentence to mean that the MCU may take ~100ms to boot in the worst case scenario to warn customers that care about power up time for their application. 

    Also, the document that you are referring to is not directly applicable for the F2837x MCUs: 

    Anyways, none of these MCUs have a requirement to hold XRSn low at power on. I think the point was always for users to calculate how long it will take for the MCU to start executing user code.

    In your case, if you hold XRSn low for 200ms at power on, you can always expect your code to begin execution ~1ms after releasing XRSn. 

    Best Regards,

    Ben Collier

  • 0 in reply to Benjamin Collier
    TI__Expert 3750 points

    Hi Ben,

    Thanks for the clarification and for catching the warning in that document. I definitely missed that. 

    Knowing this, I am now wondering why I had an issue programming the MCU.  If there isn't any requirement on the external reset signal, then why does a 10ms external reset on power up not work while a 200ms external reset does?

    When I initially powered on the boards, I was unable to program the DSP using Uniflash. I discovered that the DSP was unhappy with the reset timeout duration I had originally set up (10ms) by leaving the CT pin on the TPS3703s disconnected.  If I populate the 10k pull-up to VDD giving at timeout of 200ms I am able to successfully program.

    Any thoughts?

    Best,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 36526 points

    Luke,

    Can you share the schematic for the XRSn circuit? Could you also share the circuits at all of the power pins for the MCU?

    Thanks,

    Ben Collier

  • 0 in reply to Benjamin Collier
    TI__Mastermind 36526 points

    Luke,

    I checked schematics offline and they looked correct. 

    Luke said:
    When I initially powered on the boards, I was unable to program the DSP using Uniflash.

    Can you give more details about this? What error code did you get from Uniflash? 

    Best Regards,

    Ben Collier

  • 0 in reply to Benjamin Collier
    TI__Expert 3750 points

    Hi Ben,

    Here is the error they were seeing. 


    Let me know if you need additional information.

    Best,

    Luke 

  • 0 in reply to Luke
    TI__Mastermind 36526 points

    Luke,

    Honestly, I am not that familiar with Uniflash. It would be better for me if we could continue to debug this on CCS. Is this possible? 

    Also I will be out until Monday, so I won't be able to follow up any more this week. 

    Best Regards,

    Ben Collier

  • 0 in reply to Benjamin Collier
    TI__Expert 3750 points

    Sure, what would you like to see from the customer or have them try? I'd like to be able to give them something to at least try before next week if possible.

    Not sure if anyone else could take a look at this one in the meantime either. 

    Thanks,

    Luke

  • 0 in reply to Luke
    TI__Prodigy 440 points

    Hi Luke,

    I apologize, the current expert is out of office until Monday and is unable to respond until then. 

    Best Regards,

    AJ Favela

  • 0 in reply to AJ Favela
    TI__Expert 3750 points

    Hi Ben,

    Any update here? Customer is wondering if we could get on the phone to talk through this easier... understand you all are busy however.

    Any specifics on the SW needed to be installed? This team typically doesn't have the source code and just uses the compiled binaries to program through UniFlash.

    Best,

    Luke

  • 0 in reply to Luke
    TI__Mastermind 36526 points

    Luke,

    Let me follow up offline, I think this will be difficult to diagnose without walking through their entire bootflow. 

    Best Regards,

    Ben Collier