• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 100 subscribers
  • Views 577 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.

AM3354: AM3354 Touch Panel issue

Chihiro Inoue
Prodigy 10 points
Part Number: AM3354

Our device uses TSC_ADC for touch panel operation.

When FSM_BUSY in ADCSTAT register becomes busy, touch panel operation does not work.
Please let me know the conditions to be FSM busy.

We changed the source code of the titsc_irq() function in ti_am335x_tsc.c as follows.


[Before]----------------------------------------------------------------------

if (irqclr) {
　　　titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
　　　if (status & IRQENB_EOS)
　　　　　am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
　　　return IRQ_HANDLED;
}
return IRQ_NONE;

-------------------------------------------------------------------------------

[After]------------------------------------------------------------------------

if (irqclr) {
　　　titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);

　　　　　am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
　　　return IRQ_HANDLED;
}
return IRQ_NONE;

-------------------------------------------------------------------------------

Our source code changes no longer cause FSM busy.
Are the source code changes we made correct?
If this change we made is correct, why is FSM busy no longer occurring?

Best Regards,
Chihiro

  • 0
    TI__Guru** 101650 points

    Hello Chihiro,

    What version of Linux are you running on the AM335x? Is the ADC being used by anything other than the touchscreen driver?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 10 points

    Hello Nick

    Yes. Linux is running on our terminal.

    The Linux version is Ti's Processor SDK 1.0.0.3.

    The ADC uses STEP1 to STEP4 for reading voltages in addition to the touch panel.
    Regards,
    Chihiro

  • 0 in reply to Chihiro Inoue
    TI__Guru** 101650 points

    Hello Chihiro,

    Ok, unfortunately that SDK is too old for me to support on the forums (it's about 8-9 years old!).

    What I can tell you is that the ADC driver got a bunch of updates and bug fixes after SDK 1.0. I cannot remember exactly which releases they are, but if you look at the latest version of the AM335x Linux SDK you will see that the driver has changed a lot. I would first try migrating to the latest version of the AM335x SDK. If you cannot do that, you can at least reference the drivers in the latest version of the SDK.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 10 points

    Holle Nick,

    We know we are using an older version of the SDK.
    We have checked the drivers for the latest SDK and have confirmed that the functions we have fixed are not fixed in the latest version of the drivers.


    Regards,
    Chihiro

  • 0 in reply to Chihiro Inoue
    TI__Guru** 101650 points

    Hello Chihiro,

    The challenge here is that I cannot tell you exactly why the FSM state is busy. All that tells us is that the ADC is doing something. Exactly what it is doing, and why it is never going IDLE (if that is what is happening), is not something we can tell just from the FSM state value.

    It is entirely possible that a different part of code that was changed over the past 8-9 years fixed the actual issue you are running into, and removing the check "if (status & IRQENB_EOS)" is just hiding the problem instead of fixing it.

    Unfortunately, TI cannot support backporting driver changes from later versions of Linux to earlier versions of Linux, so I am not going to be able to do much to help you here.

    If you want to dig more into the details of exactly how the ADC state machine works, you can take a look at the Technical Reference Manual (TRM) figure "Sequencer FSM" and the section that follows after it.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 10 points

    Holle Nick,


    Please tell us the following about the FSM_BUSY bit.

    1. Is it correct that the reason why the FSM_BUSY bit is "1" can be confirmed by STEP_ID in the ADCSTAT register?

    2. Is the FSM_BUSY bit "1" when the STEP_ID of the ADCSTAT register is in Charge state or SETP1-15 state?

    3. What operations are required to prevent the FSM_BUSY bit from going from "1" to "0"?

    4. If the FSM_BUSY bit does not change from "1" to "0", how can I return it to "0"?
        Is it possible to set only the FSM_BUSY bit to "0" without resetting the CPU?

    5. When the touch panel stops working, the FSM_BUSY bit does not change from "1" to "0", but the STEP_ID bit is IDLE.
       Is this normal?
       If it's abnormal, are there any reports other than us that it's in such a state?

    Regard,
    Chihiro

  • 0 in reply to Chihiro Inoue
    TI__Guru** 101650 points

    Hello Chihiro,

    I am reassigning your thread to a member of our hardware team to discuss the ADC state machine in more detail.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 101650 points

    But please do keep in mind that the easiest course of action (if you want TI to be able to support your software) would be to migrate to the latest version of the AM335x Linux SDK.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru**** 192209 points

    Hello Chihiro,

    Please refer some of the threads and key observation/recommendations.

    Do you see this issue on a specifc board or on multiple boards. is there a specific use case when the issues happens?

    Have you considered all the design guidelines or recommendations to ensure there are no external noise sources or transients that are being coupled.

    (+) AM335x ADCSTAT:FSM_BUSY stuck at '1' - INT- Processors Forum (Read-Only) - INT- Processors (Read-Only) - TI E2E support forums

    This issue seems partially related to system implementation, because we have customers using the ADC without any issues. At this point we can only recommend customers try to reduce the noise source that seems to be causing the issue.

    There is no way for software to recover from this condition.

    (+) AM3354: ADC FSM_BUSY recovery - Processors forum - Processors - TI E2E support forums

    An unexpected event must have caused the Touch Screen/ADC state machine to enter an invalid state if it hangs.

    There is no way to guarantee every hang will have the same result.  There may be cases where a sequence like the one mentioned does something that allows the state machine to recover, but there may be others that will not respond to the sequence.

    The only way to guaranteed it recovers from a hung state is to reset the state machine. The only way to reset the state machine is applying power on reset to the device.

    (+) AM3354: ADC FSM busy issue - Processors forum - Processors - TI E2E support forums

    (+) AM335x TSC reset - Processors forum - Processors - TI E2E support forums

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 10 points

    Hello Sreenivasa,


    This issue is occurring on multiple boards.
    This problem occurs when the system is under heavy load.

    We designed our boards by reviewing the design guidelines and recommendations.

    When we try to review the following thread, we get a "Page Not Found" message and cannot review it.

    Please let me know how we can check the threads.

    (+) AM335x ADCSTAT:FSM_BUSY stuck at '1' - INT- Processors Forum (Read-Only) - INT- Processors (Read-Only) - TI E2E support forums


    Regard,
    Chihiro

  • 0 in reply to Chihiro Inoue
    TI__Guru**** 192209 points

    Hello Chihiro,

    Please refer below. 

    Hello AM335x fans,

    We do have an industrial display application using 4-wire resistive touch screen, running 3.2.23 Kernel. From time to time the touch screen stops responding. Debugging of ti_tscadc.c shows that FSM_BUSY in ADCSTAT stays stuck at '1' and there are consequently no other further conversion results added to FIFO1.

    The issue is still being investigated, but it appears clearly to be very the same as discussed for example here, here, here, here or here.

    It seems the ADC FSM to be extremely prone to noise.

    1) Is there any further result or advice pointing to what may be the root cause of these issues or how to mitigate it (other than to follow general EMC guidelines for HW design)?

    2) Can you recommend any reliable way how to recover the FSM_BUSY by means of SW? So far the only really working option to recover that has been found is complete device restart, which is not exactly satisfactory.

    Thanks and best regards,
    Roman.

    • Offline 
      TI__Guru 51675 points
      Your first E2E link contains the latest discussion on the topic. We are not actively working the issue because any solution that would allow software to recover from this condition requires a silicon spin. Currently there are no plans to spin the silicon.

      This issue seems partially related to system implementation, because we have customers using the ADC without any issues. At this point we can only recommend customers try to reduce the noise source that seems to be causing the issue.

      There is no way for software to recover from this condition.

      Regards,
      Paul
    •  in reply to peaves
      TI__Expert 4590 points
      Thanks for clarification, Paul.
      Best regards,
      Roman.
      Regards,
      Sreenivasa