TSS_Task does not update TSS internal data

[francescoprospe]

Hi there,

I'm using TSS on a PT32, 6 electrodes. My application aso uses timers and flash, so I have a bunch of activies running.

What's happening right now is that TSS_Task does not update TSS internal data, after the first flash write.

The main loop looks like the following:

void main(void)

{

  /*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/

  PE_low_level_init();

  /*** End of Processor Expert internal initialization.                    ***/

  /* Write your code here */

  /* For example: for(;;) { } */

  /* various inits */

  for(;;){

   ret = TSS_Task();

   if (flash_write_requested == 1) {

   Cpu_DisableInt();

   if (Report_Update_Flash_Data() == 0) {

   Debug_Print("Report written successfully.\n\0");

   } else {

   Debug_Print("Error writing flash report.\n\0");

   }

   flash_write_requested = 0;

   Cpu_EnableInt();

   }

}

So I do TSS_Task as often as I can optionally writing the flash whenever needed (don't mind lagging a bit though).

After the flash write (that completes just fine), the application continues to run but the TSS_Task seems to do nothing

(and its computation time is significantly shorter).

Is there any way to detect what's happening inside it?

P.S. Sorry but I don't know how to format code (input form behaviour on my browser is pretty crappy).

P.P.S I can't post all the project but I can give further info to clarify the situation.

Thanks for the (eventual) suggestions.

BR,

Francesco

[francescoprospe]

Hi Pavel,

Hi all,

based on what Pavel pointed out (citing the reference manual)

DC tracker and Negative baseline drops are disabled

when shielding is active.

So we tried to manually trigger recalibration (to update baselines) setting

recalibration bits (hw and sw) through SetSystemConfig().

The SetSystemConfig is called every 3 seconds but  recalibration is

performed with a different (longer) period.

The baseline behaviour of this approach are clumsy.

Testing our application in an environment with a lot of steam,

signals drifting is rapid and recalibration is not quick enough to

compensate.

We tried to periodically riconfigure (through calling Configure()) all the

electrodes.  If a finger happens to be on an electrode, calibration rises the baseline

for such electrode and baseline remains high for some seconds.

This behaviour is unacceptable.

Is there a way to maintain adaptability togethere with shielding?

We have only one common shielding electrode.

Could providing a separate shielding electrode for each standard electrode

improve this situation?

Thanks for your time,

F

[pavel_sadek]

Hi Francesco

I  guess it can be done, I would not do new call of Configure();

I would rather like to point you to setting Manual Recalibration starter bit in System Configuration register.

Additionally I would suggest you to block your periodical update when any electrode is in touched state.

Pavel

[pavel_sadek]

Hi Francesco

ADC is noisy from TSI point of view. So I would recomend to disable ADC every time when conversion is completed (in the ISR).

Some TSI inputs are suffer more compare to others...

Pavel

[francescoprospe]

Hi Pavel,

thanks for such info.

To be really sure, I have decided to serialize the TSS_Task call and the ADC operations (from Enable, passing by Measure,GetValue to Disable).

In this way, the two devices shouldn't be concerned about each other. I an now testing this idea.

In the end I have a dumb (in my opionion) question.

In the CPU component, I couldn't find the routine to produce software reset of the MCU. The PE should give that out to the user,

Where can I enable/find it?

Thanks for all the help you provivded me! :smileyhappy:

Good work,

F

[pavel_sadek]

Hi

the synchronization and disabling of ADC will work for sure.

in S08 devices you can do the SW reset in several ways:

one is while(1); loop when COP is enabled - it will cause wdog reset

another approach is use of illegal adress or illegal opcode

for illegal opcode you can use some instruction which is not defined...

In the event of faulty coding or disrupted software execution flow due to a disturbance, all HCS08

microcontrollers include on-chip features to generate a system reset, which will then restore normal MCU

operation. The illegal op-code (ILOP) bit in the System Reset Status (SRS) register will generate a reset

upon detection of an illegal op-code. For example, the STOP instruction is considered illegal if stop is

disabled by STOPE=0. Likewise, the BGND instruction is considered illegal if active background mode

is disabled by ENBDM = 0. The ILOP reset can also be used strategically for system protection to handle

code runaway.

Pavel

[francescoprospe]

Hi Pavel,

thanks for the tip about software reset methods.

In my firmware it seems eventually two keys get stucked.

The keys are adjacent and one is the shield  of the other (to eliminate cross-talking).

I have the Stuck-key function enabled in my configuration (after 0xFF TSS_Task invocations) but it doesn't seem they are correctly reconfigured.

Is there a way to debug this behaviour?

F

[francescoprospe]

Furthermore, TSS is not updating any baseline. I have both DC tracker (default balue = 100) and Negative Baseline Drop enabled in my configuration.

TSS_Task is executing fine (based on its return value). Any thoughts?

[pavel_sadek]

baseline is not updated in several occasions, in TOUCHED state and is some advanced features like shielding or water tolerance

from ref manual:

It is important to note that analog decoders automatically disable dc-tracker on all electrodes assigned to the control if at least one electrode from the control is touched. If all electrodes from the control are released then dc-tracker automatically re-enables these electrodes. However, manual settings of the register are allowed.

Shielding function and Water tolerance

The shielding function may further improve the TSS noise immunity and water tolerance. The function compensates signal drift on a regular electrode by a special shielding electrode signal. The function can be used in the standard shielding mode described in Section A.3.10.1, “Standard shielding function.” And water tolerance mode described Section A.3.10.2, “Water tolerance mode.” It is important to note that the DC-Tracker function and Negative Baseline Drop function are not performed on shielding, or shielded electrode. For more information on how to enable the shielding function, refer to Section 2.1.9, “Shielding function.”

[francescoprospe]

Hi Pavel,

thanks for all the support.

I'd like to close the thread (if I am able to). If a Freescale member is necessary , please do so.

Thanks again.

F

[pavel_sadek]

You are welcome :smileyhappy:

[francescoprospe]

Hi Pavel,

sorry for the delay in the response but I was busy on other aspects of the firmware.

Now, coming to the Faulting behaviour  I resume my situation:

My firmware interacts both with TSS and one ADC channel.

If I disable (commenting it out) the ADC measurement (*_MeasureChan()) all goes fine. no fault at all.

If I re-enable it, the fault callback fires with faultElecnum = 4 and DataCorrpution flag enabled.

The ADC measurement is non-blocking and is invoked every 5 seconds.

Is there any relation between TSI and ADC ?

Re-configuring the TSS library every fault seems pretty crappy solution to me so I hope I can sort this matter out somehow.

[francescoprospe]

Hi all and hi Pavel,

the same problem appeared also in another project (with no flash).

I adopted the while(TSS_Task() == TSS_STATUS_PROCESSING) in the main function.

Besides, what is the best approach to call the TSS_Task() ? in the main function or in a timer ISR?

Through the debugger, the TSS_Task() is called but through the Freemaster tool, it stops updating the readings.

This behaviour is similar to the case in which the interrupts are disabled, but in my project I do not disable them.

What is the core register bit that is affected by Cpu_DisableInt() and Cpu_EnableInt() ? (so I can tell if this is the case?)

I tried brekpointing the TSS fault callback but it appears to be never called. *edit

The fault callback is called with parameter 255 (but I have only 6 electrodes).

I hope you can give me some suggestions.

Thanks for your time,

F

[pavel_sadek]

Hi Francesco

the way of TSS_Task() calling is up to you - you can use both ISR or from the loop.

global interrupt is toggled by instructions SEI and CLI (previously mentioned macros are just allias) and are changing condition code register - I bit. You can find it under Core Registers / SR / I Bit Field in Code Warrior.

what do you see in faults register? 255 is not valid information

Pavel

[pavel_sadek]

Hi Francesco,

do you have TSS configuration between "various inits"?

I am assuming you are using TSI module with TSS.

Another point is - you are using TSS_Task(); in non blocking manner, I would rather recommend use of

while (TSS_Task() == TSS_STATUS_PROCESSING);     /* Executes the TSS main task */

it will not allow you to get into next if statement when touch task is performing (Task is causing TSI interrupt internally)

Pavel

[francescoprospe]

Hi Pavel,

Yes, the (void)Configure(); is called. (until the first write the electrodes behaviour is correct);

I've tried your blocking solution but, after the flash write, the behaviour is not changed. TSS_Task seems to return TSS_STATUS_OK.

I remark the facts that:

1) the TSS_Task is much much faster than before the write so I assume it somehow tends to skip some internal step;

2) the application continues running (other ISRs)

Long from understand the situation.

BR,

F

[francescoprospe]

Hi Pavel,

between the last two flash write routines, I wasn't waiting the end of operation with IFsh1_Busy(0).

Introducing it seems to solve my current misbehaviour, but I reserve my doubts for the final step of integration.

Thanks for the time, Pavel :smileyhappy:

I hope to not bother you (all) further. Believe me, I DO hope so.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

P.S. Pavel, I read late your last answer. Thanks for the suggestions (I was not well aware of the next TSS debugging steps).

BR,

F

[pavel_sadek · Accepted solution]

HI

well,

while loop is essentialy the must here as we need to finish the measurement of complete sequence (all 6 measurements in your case). Disabling interrupts in between causes failure of complete state machine of TSS.

if you have TSS_STATUS_OK then the measurement was successfully done.

I would start with onfault event, place breakpoint there and check if it is entered, when and what fault it is.

The other thing to check are enablers before and after falshing.

Pavel