Must TSC be in IDLE state to detect pen events?

Bruce,

There's a lot of information here so I want to make sure I'm getting the main objective. You're trying to setup an input to continuously sample a voltage divider while allowing for HW Pen Events to preempt in the event of a touch?

-Tyler

Yes.  I want the normal 4-wire touchpanel state machine to preempt a continuously-sampled input on AN5 when the panel is touched.

While I still would prefer to use the TSC as described above, I also tried changing the HW_event_mapping bit to 1 in the TSC CTRL register, changing the step to be in HW continuous mode, setting ADC_EVT_CAPT = 1 to select TIMER4, and focing a timer4 IRQ by writing 7 to the IRQSTATUS_RAW register (since for some reason I haven't been able to set the IRQ from the timer itself), and I expected this to update the ADC value read (and put into the FIFO for test purposes).  I verified that the IRQSTATUS_RAW value reads back as 7.

However, this was unsuccessful:  toggling the IRQ did not cause the ADC value to follow the test potentiometer in the voltage divider to a dramatically different value, although it did change by a few bits.  It was not until I turned it back to SW continuous mode that it began tracking the pot again.

I would be willing to have the touchscreen preempt the power monitor via Timer4 in scheduling the ADC if I do not have to field an interrupt to do so, which I beleive is the intent of the external HW event shown in Fig 12-1.

Hey Bruce,

I don't see this stated anywhere above: are you configuring the TSC_ADC_SS for the 4 wire TSC/4 wire ADC setup? Or are you using the 8-wire TSC setup and working in the ADC functionality? Is it just the 1 ADC channel that you are using for the powerloss reading?

Thanks,

Ian

Ian-

Sorry I left this out.  The ADC is configured for a 4-wire touchpanel and a single ADC input for the powerloss detector.  The other 3 inputs are not being used at present.  The driver provided in the BSP was modified by adding an ADC step for the powerloss check as described earlier in the thread. 

Thanks,

Bruce

Bruce,

Are you using an EVM or your own hardware? If an EVM, which one?

Can you share some of your register settings please:

-CTRL register (least significant 10 bits is fine)

-StepEnable register

-StepConfig register for each enabled step

Can you also tell me how you are handling the range interrupt that you are using for the powerloss measurement? I don't know if you can assign this interrupt only to specific channels, like you would want to do (not saying you can't, I'm just not sure). When you were able to get the LED to light up for PEN DOWN, did you have this interrupt disabled?

Thanks,

Ian

Ian-

We are using our own hardware, with a 4-wire touchscreen and a single (for now) analog input from a voltage divider across the power circuit.

CTRL register is currently 0x2A7.  Note the HWPREEMPT bit, expecting this to allow a pen event to prevail over a software-continuous step

StepEnable register is set to TSCADC_STPENB_STEPENB when using the touchpanel only, with the next bit (value 0x2000) set also when using the powerloss detect circuit

Stepconfig registers for touchpanel (including idle and charge) are unchanged from the driver save that the y coordinates are sent to FIFO0 instead of FIFO1 so that FIFO1 can be used for the powerloss values  stepconfigy = TSCADC_STEPCONFIG_MODE_HWSYNC |    TSCADC_STEPCONFIG_2SAMPLES_AVG | TSCADC_STEPCONFIG_YNN |    TSCADC_STEPCONFIG_INM; //| TSCADC_STEPCONFIG_FIFO1;

Apart from this tsc_step_config() and tsc_idle_config() are unchanged.  tscadc_getdatapoint() was modified to extract y data from FIFO0,using the STEPID bit to distinguish x values from y, and the FIFO0 threshold was adjusted accordingly

The powerloss step is configured as follows:  

// Set up powerfail detect  DWORD stepconfig_powerloss =  ( 1<<27) // range check
         | (1 <<26) // FIFO 1
        | (0 <<25) // single-ended diff cntl
        | (0 <<23) // RFM = VSSA
        | (5 <<19) // INP = AN5
        | (9 <<15) // INM = VREFN
        | (0 <<12) // RFP = VDDA
        | TSCADC_STEPCONFIG_2SAMPLES_AVG
        | (0 <<0) // mode = SW one shot
 //        | (1 <<0) // mode = SW continuous
//        | (2 <<0) // mode = HW one shot
//        | (3 <<0) // mode = HW continuous         ;  s_TouchDevice.regs->tsc_adc_step_cfg[STEP_POWERLOSS].step_config = stepconfig_powerloss;  s_TouchDevice.regs->tsc_adc_step_cfg[STEP_POWERLOSS].step_delay = TSCADC_STEPCONFIG_SAMPLEDLY | TSCADC_STEPCONFIG_OPENDLY;

This is observed to work:  powerloss will be detected when this step is enabled and active, as verified by the LED

As you can see, I have tried several regimes of operation as described earlier in this thread

Note that the range check bit is set per step, so only the powerloss step is being range-checked. 

I am handling the range interrupt in PDDTouchIST() by checking the TSCADC_IRQENB_OUT_OF_RANGE bit in s_TouchDevice.regs->irq_status_raw.  I then clear the interrupt, although the touchscreen no longer matters if I am losing power

As described previously, I am unable to detect pen operation to light the LED when I have this step enabled and active (SW continuous), despite having set the HW_PREEMPT bit in CTRL.

As also described previously, I have also tried adding a "soft idle" step with the tsc_idle_config() value used but the mode set to SW continuous under the hypothesis that pen down can only be detected in this state, but to no avail:  if any SW continuous steps are enabled, the touchpanel does not work

I therefore surmise that the state machine may have to be in idle as well, hence the question that opened this thread

My fallback has been to run in SW one shot mode and have the WaitForSingleObject() call specify a 1 msec timeout to periodically set the bit.  However I really don't want to have to rely on software intervention to do the interleaving.

Can you send me an example using the AM335X EVM with hardware interleaving? , i.e. sharing the ADC between a 4-wire touchpanel and an external circuit performed without using a software timeout but instead using either (in order of preference):
a) HW_PREEMPT bit to prevail over a perpetually-enabled SW continuous step, as the manual describes

b) Turning off the SW continuous step when the pen-down interrupt is received and reenabling it upon pen up (I've tried this also, of course, unsuccessfully)

c) Use of TIMER4 and rather than the pen event to read the touchpanel via the HW_event_mapping bit and  ADC_EVT_CAPT = 1 without requiring that software field the TIMER4 interrupt

Thanks,

Bruce

Bruce,

I'm going to look for some example code for you.

In the meantime, which FIFO are you loading with the ADC values for powerloss? I realize that you are relying on the Range interrupt and therefore not doing anything with them anyway, but they are still going into one of the two FIFOs. Default is FIFO0 I believe.

So what may be happening is that your HW pre-empt is working, the ADC statemachine services the TSC channels, and then when it goes back to continuously sampling the powerloss channel, this overflows the FIFO and you lose your TSC data. You can check for this condition with the FIFO OVERRUN interrupt flag. However, you may already be processing them quickly/correctly so I'm not betting on this yet.

I just wanted to throw that out as a possibility while I look for some example code.

Thanks,

Ian

Ian-

Thanks for getting back to me.

As noted in the thread, I am using FIFO 0 for the touchpanel and FIFO 1 for the powerloss data.  I do not enable FIFO threshold interrupt for channel 1 so the powerloss data should proceed into the bit bucket.  FIFO threshold is enabled for FIFO 0.  The touchpanel operates out of FIFO 0 ok unless I enable the powerloss step.

Bruce

Sorry I missed that bit about FIFO1, I see it in there now! Ok so I guess that isn't it.

I'll get back when I find a suitable example.

-Ian

Great- looking forward to it.

Thanks,

Bruce

Bruce,

This wiki page has info on how to get Touchscreen support from our linux git tree. You can do this on an EVM just to see the "normal" way to set up the TSC. I'll keep looking for examples that specifically use 4-wire TSC w/ additional ADC sampling.

-Ian

Ian-

Thanks for your reply.  We already have touchscreen and backlight support and are using WinCE.  I looked previously at example driver code for Linux and it uses a timer with software intervention to schedule the ADC sampling via software rather than using the hardware mechanisms we have been discussing.  The comments indicate that there are performance problems with it, and is not sampling nearly fast enough as it is.  Sorry not to have mentioned this earlier, but I think this is a dead end.

Any news on the hardware front, or examples that use the hardware mechnisms?

Regards,

Bruce

Bruce,

Do you have this AM335x EVM: http://www.ti.com/tool/tmdxevm3358 ? If you do, then you can download the Linux BSP for the EVM, which has an ADC Driver which supports 4-wire mode. We could work from there.

I didn't realize that you were using WinCE. I probably won't be able to find any WinCE examples for you. Anything we find will be written in a linux driver, and then you'll have to port it over.

You mentioned your stepconfigy is set to: stepconfigy = TSCADC_STEPCONFIG_MODE_HWSYNC |    TSCADC_STEPCONFIG_2SAMPLES_AVG | TSCADC_STEPCONFIG_YNN |    TSCADC_STEPCONFIG_INM; //| TSCADC_STEPCONFIG_FIFO1;

What is TSCADC_STEPCONFIG_MODE_HWSYNC? HWSYNC has both single shot and continuous mode in the stepconfig registers, so I would expect this to be TSCADC_STEPCONFIG_MODE_HWSYNC_SINGLE or _CONTINUE. Which are you setting? I ask because I found the following in the AM335x ADC Driver Guide: "When the user wants to continuously take samples, continuous mode needs to be enabled. One cannot read ADC data from one channel operating in One-shot mode and and other in continuous mode at the same time. " I'm not totally sure if that is speaking about our specific ADC driver in our BSP or if it's a comment on the ADC functionality overall. If it's true, the answer to your original question may be that yes, your state machine needs to be in IDLE. But I'm not toally convinced yet.

-Ian

The above bolded statement couldu also explain why the other implementation you referenced earlier used a timer: so that you could still use SingleShot mode but have it repeat.

-Ian

Ian-

I can live with Linux example code instead of WinCE as long as it addresses the problem at hand.  As I mentioned, I have reviewed the Linux driver in 0777.ti_tscadc.tar.gz

TSCADC_STEPCONFIG_MODE_HWSYNC is defined by the WinCE BSP as 0x2, i.e. specifying hardware one-shot mode.  The oneshot is activated by the pen-down event, so these steps are always enabled.  This mechanism is from the BSP

The comment you identify appears to pertain to the rather limited driver described in the document you reference (where it is definitely true) rather than the hardware- were that the case so fundamental a statement would belong in the manual, which describes how software mode (presumably continuous, per the comment about the software's responsibility to disable) and hardware mode steps can be coordinated by the HWPREEMPT flag in the CTRL register, but this is speculation also.

As a parallel line of attack, can you contact a hardware engineer in TI and forward this thread to find out how the ADC mechanisms we're looking at work?

Thanks,

Bruce

Bruce,

When you configured your continuous software steps, did you configure the AFE transistors to be the same as the idle step or are they all turned off? Without doing this, the AFE will only have a chance to see a pen-down event during the idle step so you will most likely miss these events during your software step if the switches are not configured.

Regards,

Tyler

I had added a "soft idle" step configured exactly as the IDLE state for precisely this reason, but it did not appear to do any good, as discussed above in the thread.  It was the second sw continuous step, the other being the powerloss detection on ADCIN5.

However, I'm willing to do whatever you can get working, so if you can create an example that works on the EVM under either Linux or WinCE I'm happy to make the corresponding changes and let you know the result.

Thanks,

Bruce