• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 794 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.

AM3352: DMTIMER_1MS soft reset issue

Joshua Trejo
Prodigy 90 points
Part Number: AM3352

Hi, 

We are using the AM3352 on a custom PCBA solution.  We are utilizing DMTIMER_1ms to generate a 1ms tick with an external 32Khz oscillator as the clock source.  

After configuring the RTC for the external clock source and performing the clock management, we perform a soft reset (TIOCP_CFG register) and pend for confirmation that reset is done (TISTAT register) before starting the timer configuration and eventual start of the timer.   We've observed on one PCBA that the bit ResetDone on the TISTAT register never returns "rstcomp" (1) to indicate reset is complete.  If we remove the pend we eventually Data Abort in other instructions after configuration is completed.

We have examined the PCBA and cannot find any reason to feel we've injected this in error.  We've had over 100 boards built and this is the first instance.  

Is there any insight as to why this issue would occur?  The TRM is light in content on the Soft Reset functionality of DMTIMER_1ms.  Right now we're classifying this as a bad processor but we'd like to get more clarification for future.

Thanks!

  • 0
    TI__Guru**** 393215 points
    Hi,

    What software are you using?
  • 0 in reply to Biser Gatchev-XID
    Prodigy 90 points

    Hi Biser, 

    Thanks for your reply!

    We are executing our software on an RTOS (Micrium uc-II).  Let me know if you have any other questions!

  • 0 in reply to Joshua Trejo
    Prodigy 90 points
    Any information on this question?
  • 0 in reply to Joshua Trejo
    TI__Genius 15920 points
    Hi Joshua,

    Sorry for the delays. I have a few questions about your use case.

    Does this erroneous board always exhibit the same behavior after a reset? Also, can you read the RESETDONE bitfield before issuing the soft reset? What value does it return?

    Regards,
    Melissa
  • 0 in reply to melissaw
    Prodigy 90 points

    Hi Melissa, 

    This issue is continuous on this erroneous board.  We've never been able to get passed this issue in our power-on testing.  The RESETDONE bitfield was read during our initial investigation prior to soft reset and no issues were reported (i.e. bit was 1 as expected).  I can have this test run again if we'd like to get a confirmation.  

    Thanks!

    Josh

  • 0 in reply to Joshua Trejo
    TI__Genius 15920 points

    Hi Josh,

    Below are a few additional tests that can be run on your erroneous board.

    1. Do you see this same behavior after performing a warm reset and cold reset of AM3352?  

    2. Is the external 32kHz oscillator running correctly on this board?  Below are two suggestions of ways to test for this:  

    a. On the failing board, allow the oscillator to start running and then use a high impedance passive probe to observe the oscillator on a scope.

    b. On a working board, disable the 32kHz oscillator and see if you can reproduce the behavior seen on the failing board.

    Regards,

    Melissa

  • 0 in reply to melissaw
    TI__Genius 15920 points
    Hi Josh,

    It's been awhile since I've heard from you, so I'm marking this ticket as "TI Thinks Resolved."

    Regards,
    Melissa
  • 0 in reply to melissaw
    Prodigy 90 points

    Hi Melissa, 

    Apologies for the delay, we hadn't had time to get to this but we did perform the investigations recommended.  See results below:

    1. Do you see this same behavior after performing a warm reset and cold reset of AM3352?  

    On the failing board, the same behavior exists after cold and warm resets.

    2. Is the external 32kHz oscillator running correctly on this board?  Below are two suggestions of ways to test for this:  

    a. On the failing board, allow the oscillator to start running and then use a high impedance passive probe to observe the oscillator on a scope.

    When we probed the oscillator, we observed a very weak signal oscillating after setting the oscillator source.  We replaced all components that we could on that circuit and the issue was still present.  We are suspecting either a bad ARM chip or an issue during assembly.  We have sent the board back to our board house for x-rays.

    b. On a working board, disable the 32kHz oscillator and see if you can reproduce the behavior seen on the failing board.

    We disabled the oscillator by tying XTAL pins to ground and were able to replicate this issue.  

    Since we've been able to isolate the issue to either the ARM chip itself or assembly, I believe that these recommendations resolved the issue.  We have implemented tests on our test fixtures to probe the oscillator during assembly to catch this issue.  We've assembled plenty of boards at this point and still only see this issue reliably on this board, therefore we do not suspect anything requiring further action.

    Thank you very much for all of your help!

    Josh