• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 656 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.

F28335 CPU lockup - possible causes, debug strategies, and errata

Lenio Cacula
Genius 17010 points

Other Parts Discussed in Thread: TMS320F28335

My customer is having an issue with the TMS320F28335 in which the device hangs up for an unknown reason. 

The software runs on TI-RTOS and CCS, both on the latest version.

1. What is the best method for collecting debug information that would help understanding the lockup? How can we potentially detect a division by zero, illegal operation, external memory configuration, register set, and etc. I am afraid that if we send all of this information via serial port we will end up hogging the resources of the system, especially from the control loop. Do we have other trace resources we could use?

2. Regarding the errata  "Memory: Possible Incorrect Operation of XINTF Module After Power Up." 

2.a - when this occurs at power up, what is the actual mechanism that causes the CPU to hang?

2.b - is it possible for this same lockup mechanism to occur after initial configuration of the External Memory Interface during subsequent execution of application code?

2.c - Is the External Memory Interface configuration protected from alteration after initial configuration, or can it be changed on the fly?

2.d - if it can be changed on the fly, is it common practice to only set this once at Boot, and never check it again?

2.e - can the external memory interface configuration status be read from the CPU registers?

2.f - is it possible for the external memory interface to be altered by the code after initial configuration ?

2.g - Any additional concerns when using the XINTF in 8-bit mode

3. What are other errata items - if any - we should examine for debugging a CPU lockup?

I am getting more information about occurrence of the issue.

Thank you!

  • 0
    TI__Genius 17010 points
    As for the occurrence: the problem is generalized; it happens in multiple units. It can appear anywhere from 1 hour to 48 hours, quite randomly. It has the same signature as the External Memory Interface lock-up issues in the errata, except it is happening during operation.
  • 0
    TI__Guru* 93800 points

    Lenio Cacula said:
    1. What is the best method for collecting debug information that would help understanding the lockup? How can we potentially detect a division by zero, illegal operation, external memory configuration, register set, and etc. I am afraid that if we send all of this information via serial port we will end up hogging the resources of the system, especially from the control loop. Do we have other trace resources we could use?

    Does the CPU hang occur only when the debugger isn't connected, or does it occur both when the debugger is and isn't connected?

    An illegal operation will cause the ITRAP interrupt to be fired.  Make sure this exists and is configured to do something so you can detect code landed there.  If the debugger is connected place a breakpoint.

    Division by zero shouldn't hang the CPU.   If they want to check for this situation they could check in code before a division.

    If the hang happens when a debugger is connected, the watchpoints could be used to monitor a range of registers for a CPU write.

    Lenio Cacula said:

    2. Regarding the errata  "Memory: Possible Incorrect Operation of XINTF Module After Power Up." 

    2.a - when this occurs at power up, what is the actual mechanism that causes the CPU to hang?

    The XINTF is not completely reset after a power-up.

    Lenio Cacula said:
    2.b - is it possible for this same lockup mechanism to occur after initial configuration of the External Memory Interface during subsequent execution of application code?

    No. If the workaround is performed, then the XINTF will be completely reset and the issue will not occur again until a power-down/up.

    Lenio Cacula said:
    2.c - Is the External Memory Interface configuration protected from alteration after initial configuration, or can it be changed on the fly?

    It can technically be written to but this is not the common practice.   If this is going to be done, there should be no accesses occurring to the XINTF when the change is made.  This includes making sure the the XINTF write buffer is empty by checking its level.

    Lenio Cacula said:
    2.d - if it can be changed on the fly, is it common practice to only set this once at Boot, and never check it again?

    It is not common.

    Lenio Cacula said:
    2.e - can the external memory interface configuration status be read from the CPU registers?

    Yes the configuration registers are both read and writable.

    Lenio Cacula said:
    2.f - is it possible for the external memory interface to be altered by the code after initial configuration ?

    I'm not sure how this question is different from 2.c?  Please elaborate.

    Lenio Cacula said:
    2.g - Any additional concerns when using the XINTF in 8-bit mode

    There are 3 XINTF specific errata - but only the one you mentioned applies to silicon newer to Rev 0.  Can they confirm that they are using a newer revision than Rev 0?

    Lenio Cacula said:
    3. What are other errata items - if any - we should examine for debugging a CPU lockup?

    For XINTF please check that the XREADY and XHOLD configuration and pin levels are correct.  Both of these can stall the CPU.

    Also make sure the configuration of the XINTF only occurs when no access is in progress to the XINTF. 

    Otherwise, having the CPU completely lockup is very unusual.  Usually when things go wrong the CPU will endup in an invalid interrupt / ITRAP. 

    It wouldn't hurt to check the other errata related to memory.


    Regards

    Lori

  • 0 in reply to Lori Heustess
    TI__Guru* 93800 points

    I would also investigate:

    • Does this occur on one board, all boards, a TI board?  
    • Did it previously work, but doesn't now?
    • Does it occur with one device, all devices?
    • Has the power/ground been carefully checked and healthy (not current limited)?
    • Is the input clock correct?  Are clock configurations correct?
    • Does it happen if the XINTF is configured for a slower  / slowest configuration?  (lead, active, trail == max values)
    • Using a scope can the XINTF pins be monitored to see if accesses are occurring?
    • Using a scope can the XRSn line be monitored to see if the watchdog is firing?  (periodic reset?)

  • 0 in reply to Lenio Cacula
    TI__Guru* 93800 points

    Lenio Cacula said:
    As for the occurrence: the problem is generalized; it happens in multiple units. It can appear anywhere from 1 hour to 48 hours, quite randomly. It has the same signature as the External Memory Interface lock-up issues in the errata, except it is happening during operation.

    I just saw this additional information.  I would ask them to double check that when they implement the work-around that they can monitor the XRSn line and see it toggle during the warm reset.  This is to confirm that the work-around was implemented correctly.

    Lori