AM3354: ADC FSM_BUSY recovery

Part Number: AM3354

Hi,

FSM_BUSY no longer occurs after source changing to the following interrupt processing.
Is it the correct process?

--------------------------------------------------------------------------------------
before
am335xOutLong(TSC_ADC_IRQSTATUS, (1 << 5)); /* int clear*/
am335xOutLong(TSC_ADC_STEPENABLE,
(((1UL << (TP_FIFO_CNT * 2)) - 1) << 1) | /* Step Enable */
(1 << 0)); /* charge step Enable */

after

am335xOutLong(TSC_ADC_CTRL, am335xInLong(TSC_ADC_CTRL) & (~1UL)); /* TSC Disable */
while((am335xInLong(TSC_ADC_CTRL) & 0x00000001)); /* TSC Disable wait */

am335xOutLong(TSC_ADC_IRQSTATUS, (1 << 5)); /* int clear*/
am335xOutLong(TSC_ADC_STEPENABLE,
(((1UL << (TP_FIFO_CNT * 2)) - 1) << 1) | /* Step Enable */
(1 << 0)); /* charge step Enable */
sysUsleep(1000); /* 1000 usec wait */
am335xOutLong(TSC_ADC_CTRL, am335xInLong(TSC_ADC_CTRL) | 1UL ); /* TSC Enable */

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

It was necessary to wait after STEPENABLE was set up, but how long does it have to wait?

Does it become FSM_BUSY if TSC_ADC is enabled after setting STEPENABLE without detecting the above wait processing or END_OF_SHEQUENCE?
In that case, please tell me why it becomes FSM_BUSY.

Best Regards,
Shigehiro Tsuda

The factory team have been notified. They will respond here.

Hi Paul,

Thank you quick reply.
I understand that FSM busy recovery is only power on reset.

But Our customer seems to be returning in the following sequence after ADC hang by FSM busy.

① Set the enable bit of the CTRL register to 0.
② Resetting the STEPENABLE register
③ Set the enable bit of the CTRL register to 1.

Will you check with your design team again?
Recovery with POR reset can not be accepted as it can not be established as their product.

Best Regards,
Shigehiro Tsuda

I'm guessing the waveforms and hex dump of the FSM busy hang is posted here?

I wonder if you are getting a FIFO overrun or underflow. From the AM335x TRM, Section 12.3.5:

The FIFO can also generate FIFOx_OVERRUN and FIFOx_UNDERFLOW interrupts. The user can mask
these events by programming the IRQENABLE_CLR register. To clear a FIFO underflow or FIFO overrun
interrupt, the user should write a ‘1’ to the status bit in the IRQSTS register. The TSC_ADC_SS does not
recover from these conditions automatically. Therefore, the software will need to disable and then again
enable the TSC_ADC_SS. Before the user can turn the module back on, the user must read the
ADCSTAT register to check if the status of the ADC FSM is idle and the current step is the idle step.

You'd want to test that theory by enabling the IRQ ENable SET bits for FIFO1 overrun and underflow, and FIFO0 overrun and overflow.

Regards, 

Nick

Hi Paul,

Thank you for quick reply.

I understood as follows.
If FSM busy occurs and TSC_ADC hangs, such software can be avoided in some cases, but in some cases it can not be avoided.
Since these conditions can not be determined,there is only POR as a method to recover from FSM busy.
Is it correct in my understanding?

Best Regards,
Shigehiro Tsuda

Hi Nick,

Thank you for quick reply.

[your question]
I'm guessing the waveforms and hex dump of the FSM busy hang is posted here?

[answer]
Yes,register dumps and waveforms are those posted here.

I will check what will happen if they enable FIFO overrun and underflow interrupts.
Are there the sample programs?

Best Regards,
Shigehiro Tsuda

I do not know of sample programs using FIFO overrun and underflow interrupts. however, I would expect the user to set the IRQENABLE_SET bits for FIFO1 overrun, FIFO1 underflow, FIFO0 overrun, and FIFO0 overflow. After the FSM busy hang occurs, I'd look to see if any of those bits are set in IRQSTATUS register.

Regards,
Nick

Hi Nick,

Thank you for various support.
I checked the customer for FIFO overrun and FIFO underflow interrupt enable.
As a result, this interrupt did not occur and the TSC ADC hung.

Best Regards,
Shigehiro Tsuda

Hello,

Ok. Brad brought up another potential software cause for a TSC ADC hang in this post, could you check if the customer is doing something like polling for ADCSTAT[STEP_ID] == IDLE before writing to STEPENABLE? If not, it would be good to add that code and see if the hangs persist.

Regards, 

Nick

Hi Nick,

Thank you for various support.
There is no such processing in customer code.
I will confirm with the customer what happens when ADCSTAT [STEP_ID] = IDLE polling processing is added before writing STEPENABLE.

Best Regards,
Shigehiro Tsuda

For future readers of this thread: Check out Brad's related comments on this post. 

Regards, 

Nick

Hi Nick,

Thank you for various support.
I confirmed Brad's comments on other post.

Our customer seems to be able to recover after TSC ADC hangs in these sequences.
It is confirmed that the frequency of occurrence varies depending on CPU load.
Therefore, we think that the cause of TSC ADC hang is probably not a hardware factor such as noise.
Is there no cause for hanging with software factors?
I think that the state machine is hanging because there is timing that STEPENABLE can not write, since it is writing at that time.

Best Regards,
Shigehiro Tsuda

Hello,

Did the hangs continue occurring after the customer added code that polls for ADCSTAT[STEP_ID] == IDLE before writing to STEPENABLE as per Brad's post? That is one software factor that could cause hangs if there is not a FIFO underflow/overrun.

Regards, 

Nick

Hi Nick,

Thank you for your support.
Updated additional information to the following post, please check.
e2e.ti.com/.../2561646

Sorry for delay.
As for the result of Brad's proposed code addition, I am checking with the customer, please wait for a moment.

Best Regards,
Shigehiro Tsuda