Reset Recovery Considerations

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 After experiencing Hard Resets due to EMI from an adjacent unit, I came to the realization that EMI Resets were going to be a difficult to eliminate. The CY8CKIT-030 was used for a development test bench; I hardly expected to do a better job of PCB design than Cypress engineers. And I would not be able to control the environment that the embedded PSoC3 would be installed in.

   

This thread focuses on trying to figure out how to "peacefully" co-exist with Resets, both Soft and Hard varieties.

   

Since there are two varieties of Resets, the first item is to determine the type currently occurring.

   

Resets of the Soft variety are easier to work with; they leave SRAM as is and the Components and Registers are not reset to DWR settings. User code is resumed at main(). The main Soft Reset is the WDT Reset. RESET_SR0 contains the identity since the Registers are not reset. But lacking in support is a means to determine where in your code the WDT tripped, and a count of how many have occurred. Because the Stack has no meaning, and the Soft Reset clears the CPU registers, "crawling" the Stack (if idata was left uncleared) could possibly answer where the WDT tripped. A count of WDT events could be a user responsibility; SRAM as a count repository is possible (but an intervening Hard Reset clears SRAM and the WDT count would be lost). The normal main() function of initializing Components should probably be skipped with a Soft Reset. If the problem section of code can be determined, then selective initialization may cure the WDT problem.

   

Hard Resets pose a significant challenge. The action to be taken is highly dependent on the functions that the PSoC3 is designed to make.

   

With SRAM clearing as an option on a startup reset, the tradeoff of fast startup versus using a Global Variable as an SRAM clearing semaphore should be evaluated. Yes, CyResetStatus could be used to see what type of Hard Reset occurred (I have done extensive research of CyResetStatus and conclude it is not currently working for PSoC3 with Creator 3.0 SP2). But if the reset is of the PRESx variety then a working CyResetStatus does not set a bit (I experienced bad enough EMI to cause a PRESx set with LVID and LVIA not activated). 

   

The Hard reset SRAM semaphore works by declaring a Global Variable that is not initialized. The last thing main() does is set the variable to a one. On entry to main(), examination of the variable shows if SRAM was cleared and thus a Hard Reset has occurred. A POR or XRES will show a zero semaphore. If the semaphore still contains the one, a Soft reset occurred (assumes that SRAM Clear remains the option).

   

How to handle a Hard reset is the main consideration. I will explore what I am considering in followup posts. I am not sure with my particular project how to handle Hard resets. This thread is to solicit comments and suggestions which are welcomed.

   

Thanks for your interest,

   

Bruce

0 Likes
1 Solution
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One thing you can do to speed up settling time for PWM filter

   

is to split the series R in the filter into two series Rs, and bypass

   

one of them with a pair of back to back diodes or schottkys. This

   

creates a non-linear filter, for large step changes opens up the filter

   

BW, and cuts down settling time. For small step changes filter reverts

   

back to more of an integrator. I used this technique in PLLs and

   

works great. You have to experiment with R values.

   

 

   

RC snubbers on relay contacts, especially if any arcing, very prudent.

   

 

   

Regards, Dana.

View solution in original post

0 Likes
99 Replies
Anonymous
Not applicable

 My project has some Time of Day dependncies. Currently supplied via the CY8CKIT-030 32k crystal clock and a few Counters. Time is set from the PC program which obviously only occurs when the PC is running and detects an incorrect time is being reported.

   

A Hard reset clears the RTC Counters thus creating a problem.

   

RTC modules with an I2C interface are available at a modest cost. RTC modules with crystals and backup batteries on a PCB are available for about $10 more for development purposes. The modules also produce a 1Hz square wave that can replace my need for a 1 second semaphore.  The PC update is a little bit different but not a significant problem to change (I2C code vs. Counter update).

   

The RTC requirement requires a redesign but is solvable.

   

The next item I need to look at is my use of two PWM outputs. A new post after I research this area.

   

Bruce

0 Likes
Anonymous
Not applicable

 A RTC followup.

   

The KIT 32k oscillator requires some time to get up and running. This is delaying the restart from a Hard reset. A POR is not a problem, but an undesirable Hard reset delay makes things worse.

   

A separate RTC module would only be started once or twice in its lifetime and thus not delay a restart. A small coin backup battery is mandatory to ensure that the RTC module does not get wiped clean on a power failure (another incremental cost).

   

The KIT 32k oscillator is best left out of the equation. Any PSoC3 clocks dependent on the 32k clock need rethinking.

   

On to the PWM outputs.

   

Bruce

0 Likes
Anonymous
Not applicable

 A retrogression,

   

"crawling" the Stack does not seem to be viable on further examination with my rudimentary Stack knowledge.,

   

The Stack contains addresses. Don't know how an address can be interpreted on the fly in main() to control subsequent recovery actions. Offline is another story but:

   

The Stack is a LIFO stack. Since we get going again in main(), main() is on the top of the stack. If remnants of the stack remain, the currnt main() entry has wiped out the area of code that was running at the time of the WDT fault.

   

Anybody like to comment on this topic?

   

Still researching PWM when I regressed!

   

Bruce

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Maybe I am wrong, but I would never tend to analyze at which point of my program an externally caused event generated a reset.What new knowlege are you expecting to get? I would tend to link an EMI event to a reset event to prove a dependency, but this should be done totally independent of the program running.

   

It could turn out to be difficult catching an EMI-pulse, but there are several possibilities like a battery-powered surveilance device, a triggering scope or LA and probably some more.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 Now on to the PWM outputs.

   

One is used to control a proportional valve that does not have a good correlation between its analog input and the resulting output flow (pressure is the significant variation cause). The PWM feeds an integrating circuit that converts it to analog and also level shifts the output. Because of this imprecise condition, a flow turbine is installed to measure the effect. There is also a time delay factor in the valve action; the time delay helps reduce any reset restart delay problems. The flow turbine can be read immediately following a Hard reset and "reverse computed" to determine a good restarting point for the PWM. The reset condition is required to differentiate from a POR vs. an EMI reset for this to function.

   

The second PWM is a "blind" output in that the PWM is in direct control of the device it feeds; no feedback. There is an interaction between the first PWM flow value and this PWM's interrupted value, sufficient I think to get back somewhere in the ballpark for a start. A delay in restarting this PWM will cause an interruption in the operation of the device; inertia of the device is somewhat of a saving factor (the device is an ECM and thus does not use a capacitor start motor, so resuming it at some indeterminate point is not a problem). Also a significant PWM step function can introduce a noticible effect. This area will require some empirical testing to smooth out the kinks. 

   

I think as a result of lesser EMI noise, the ADC DelSig and other sensors exhibit some jitter. I have coded some Exponential Smoothing routines to reduce the jitter. My code starts with an Exponential Smoothing Period of 1, incrementing by 1 each sample until the desired Period is reached. Each variable has its own desired period. I think this smoothing is "friendly" to the reset startup.

   

Next are the Digital outputs. More research before I know how the resets effect these.

   

Bruce

0 Likes
Anonymous
Not applicable

 Bob,

   

I used a triggering DSO to determine that my resets were EMI caused.

   

I don't think it is possible with my project to eliminate EMI resets.

   

The purpose of this thread is to explore how to recover from a reset; be it a WDT or EMI caused.

   

I currently use synchronized API's, the untimeliness of any one of which may lead to a WDT event. Not all of my Data Acquisition sensors are used to control the process. It would be nice to know if a WDT was caused by a reporting only sensor so I could cut it out of the acquisition. I intended to address the synchronized/unsynchronized API calls further along; your point is well taken and I am addressing it now to indicate it is an area of concern since the WDT trip is currently devoid of clues. By using timed loops and API completion tests within and including WDT "tickling", an "infinite loop" can be avoided while knowledge of where the excessive delay is occurring is at hand. A WDT trip outside of the sync API calls should hopefully be eliminated during testing and debug phases.

   

Thanks,

   

Bruce

0 Likes
Anonymous
Not applicable

 Bob,

   

On rereading your post I see what your EMI reset concern is.

   

I don't care where the EMI reset occurs in my code. It is an entirely random event. I do care about how to recover from an EMI reset.

   

I do care where a WDT event occurs in my code. It is probably in the currently executing call. Knowing where is instrumental in attempting to circumvent the problem and gives an indication if there is a specific hardware problem that needs addressing.

   

My reference to a "sync" API should read "async" API.

   

Thanks,

   

Bruce

0 Likes
Anonymous
Not applicable

A RESET in your case is not a good thing.

   
    For some issues that seems unavoidable, we normally start asking the questions   
   
    What is the purpose of knowing why it RESET?   
   
    What do you want to avoid?   
   
    What to do with this information? What to do without it?   
   
    What is the implication if do nothing?   
   

and the manager would ask

   

What is the cost of fixing or not fixing it?

0 Likes
Anonymous
Not applicable

 HL,

   

Good questions.

   

Why -- A Soft recovery is a minimal disruption. A Hard recovery is a more prolonged event.

   

Avoid -- A prolonged disruption and possible loss of control. Damage to the fairly expensive equipment being controlled (some safety "valves" are in also in control but only actuate under extreme conditions, no human lives are at stake).

   

Do nothing -- A probable "No Sale" condition. Or a "bad press" event.

   

Cost -- could result in a Go/Nogo decision on project. Costs of a workaround are a one time development cost.

   

Desirable (My project goal)-- A minimally disruptive condition as a result of a reset.

   

Thanks for making me think about your questions,

   

Bruce

0 Likes
Anonymous
Not applicable

OK, new questions

   
     1.       If there is an interruption, and not knowing when or how it was interrupted, is there a safe or acceptable sequence to restart the control?   
   
     2.       If answer to 1 is yes, what is the sequence?   
   
     3.       If there is an interruption and there is a way of knowing when and/or how it was interrupted and the system can re-establish the state of control at the time of interruption and continue ( after some delay  due to system restart). Is this acceptable?   
   
     4.       If 3 is acceptable, can the system re-establish the state of control? What information is needed?   
   
    It seems that the hardware approach (ferrite core, shielding...) is rejected already. Any reason why?   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Building fail-safe systems - and that is what I see you want to do - is a scientific job and it is - as you can see throughout the world - barely manageable. Having a high-energy cosmic particle that changes a bit in the flash over EMI events (where you focus on) to non-reactive external hardware as sensors and actuators is a wide field of events to cover with adequare provisions.

   

So handling the requirements the old-fashioned way "divide et impere" can lead us to success:

   

First, second and third points are: Shielding, shielding, shielding.

   

Shielding of the supply with ferrits, zener diodes and similar methods must be considered

   

Shielding of the inputs and outputs with similar provisions will provide leaking-in of failures through this path

   

Shielding of the complete device against magnetic or electric fields or radiation, static electricity

   

The next point is: Protection

   

As long as the device controls any external machinery (which is quite usually the case) there must be a control state at the inputs of the machinery that reflects a "safe" state. This state must be enforced on the controlling lines externally. So in case the device does not run, the controlled machine is in a safe state.

   

An indispensable point is: Self-Test

   

As you are probably aware of: Your PC does a self-test every time you switch it on, so you have to implement something similar. Checking the CPU and its environment, checking the sensors and checking the actuators (which might induce some design-considerations to "see" results)

   

Next point is Communication.

   

A safe device must be able to report its state to give the whole machinery a chance to act on changes accordingly.

   

Every PC power-supply has got a signal named "Power Good". This is the least indication a "dumb" device could deliver and which can signal the connected machine whether to trust the controlling signal or not. More complex is a "Heartbeat" signal which dynamically signals that the controller is still alife.

   

Last, but not least point is: Quality ensurance

   

Last PC comparision: When your PC was shut down improperly (Plug pulled) next time you start it you get informed about that issue. How? Just by recording the fact that the PC was powered up and by recording a power down, which will not happen in the case of the pulled plug.

   

A PSoC has got an EEProm which you could use to indicate a legal shut-down, the time (you are using an RTC) of the last power-up and when that is less than a second ago there must be something darn wrong.

   

 

   

As you can see, there are some inavitable requirements you should focus on because that will help you to build designs that you and your customer can trust on.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

"The second PWM is a "blind" output in that the PWM is in direct control of the device it feeds; no feedback. There is an interaction between the first PWM flow value and this PWM's interrupted value, sufficient I think to get back somewhere in the ballpark for a start. A delay in restarting this PWM will cause an interruption in the operation of the device; inertia of the device is somewhat of a saving factor (the device is an ECM and thus does not use a capacitor start motor, so resuming it at some indeterminate point is not a problem). Also a significant PWM step function can introduce a noticible effect. This area will require some empirical testing to smooth out the kinks. "

   

 

   

Clearly you have a feedback loop overall in system response. If you are converting PWM

   

output to DC there is a substantial delay vs ripple tradeoff in the output filter. Attached

   

is an analysis of filter approaches for simple filters. One useful way of getting at this is

   

to use matlab or Labview and simulate this. If you do not have these there are a number

   

of free spice simulators available, like LTC Spice or Tina TI.....

   

 

   

Regards, Dana.

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

"Last PC comparision: When your PC was shut down improperly (Plug pulled) next time you start it you get informed about that issue. How? Just by recording the fact that the PC was powered up and by recording a power down, which will not happen in the case of the pulled plug.

   

A PSoC has got an EEProm which you could use to indicate a legal shut-down, the time (you are using an RTC) of the last power-up and when that is less than a second ago there must be something darn wrong."

   

 

   

This approach great for situation where you are getting detectable shutdowns, but your situation

   

does not permit this.

   

 

   

Some ap notes on emi/layout that may be of help. Attached.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana, Bob, et.al.,

   

Good stuff! Plenty to keep me busy.

   

Let me reply to the points raised.

   

Prevention -- Ferrite cores tried and still in place, 15 count them, not much improvement. Same for Ceramic bypass filters. Sheilding, but adds a quantum increase in cost, as compared to learning how to co-exist. Frequency of intermittent EMI events is hard to guage, but I think some progress has been made in reducing them.

   

Protection -- Yes there is a fallback to an existing rudimentary control system (that which is used in the "plain vanilla" system and would still exist in a PSoC3 supplemented system), PSoC3 is used the supplement it for reasons of improving the efficiency and capacity. My project uses digital output driven relays to control which system is RUNning the show. First thing a reset does is to drop power to the RUN relay; causes a noticible audible change to the units operation when reverting control.w A recovery causes a reverse change (a PWM monitor component is employed, whose input is also switched, this allows the reverse to be a gradual change since the plain vanilla setting is available). I think I need to take care that the relay switching does not cause EMI (currently have coil suppression and am inclined to add contact suppression). Don't want rapid EMI events from the relays.

   

Communication -- There exists a BlueTooth radio link included. Only effective when a PC program is listening. Data transmitted includes sensor readouts, system state, and unusual conditions (sticky bits). Reset info is currently included but not very useful due to CyResetStatus current state of affairs; possibly useful statistically but not useful for remediation. BlueTooth complicates the shielding.

   

2nd PWM -- the more I think about this area, the more "other" feedback items I realize. Temperature differentials can help determine the previous settings, but are only ballpark precision indicators. There exists a delay between making a control adjustment and seeing a temperature change due to the mass of the units components (the M in E=MC**2).

   

1st PWM -- Integration circuits were designed with 5Spice, verified with analog scope, and are working nicely. Don't have any evidence of it being a source of interference.

   

A WDT followup -- With the use of async API calls and testing with faster WDT settings to detect "near WDT conditions" , a WDT reset would indicate that a significant problem has occurred. I am currently not sure a WDT recovery is a wise move, I am currently inclined to only focus on Hard Reset recovery efforts. 

   

Thanks again,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One thing you can do to speed up settling time for PWM filter

   

is to split the series R in the filter into two series Rs, and bypass

   

one of them with a pair of back to back diodes or schottkys. This

   

creates a non-linear filter, for large step changes opens up the filter

   

BW, and cuts down settling time. For small step changes filter reverts

   

back to more of an integrator. I used this technique in PLLs and

   

works great. You have to experiment with R values.

   

 

   

RC snubbers on relay contacts, especially if any arcing, very prudent.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

PWM Filtering. Interesting method.

   

However for this application it is not necessary.

   

This PWM drives a motorized flow valve (a Belimo proportional model with a 0 to 10v DC input signal). Motorized liquid flow valves are very slow unless they consume large amounts of operating power. The Belimo takes 90 seconds to go from somewhat past off to somewhat past on. It averages about 25 seconds to start a flow.  Doesn't consume much power. So PWM filtering need not be sophisticated, only somewhat linear.

   

Once flowing, the Belimo uses a "characterized flow aperature" where the flow is proportional to the input signal (they call it CCV). A nice feature because changes to the input signal produce proportional flow changes, thereby simplifying the C code to a linear function No matter where a flowing valve is positioned, an incremental signal change produces the same incremental flow change. A welcome change to what many controls exhibit; usually exponential functions with complicated C code to operate them. The other PWM drives an ECM motor where pulse width controls motor speed; good ECM motor controllers monitor speed and torque to produce and maintain a desired speed even with varying loads. 

   

Thanks,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Thanks for educating me. I enjoy new knowledge, generally speaking its cheap,

   

and very satisfying. I have an aging library, many of the

   

books contain significant industrial control optimization. My background

   

before I EE’ed was as a reactor operator on SSN583. I was responsible for

   

control and instrumentation as well, primarily based on Magamps. We handled

   

electricals and cals. But were not trained in response methods.  I have some

   

IEEE books and papers on non linear control which I would like to study again,

   

But too many interests, too little time. Now working on learning FPGA tools,

   

learning curve steep but as always building on the foundations. Ohm,

   

Thevenin, Maxwell still very much our day to day activity.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

You have a fascinating background.

   

I like to think mine is fascinating also. After engineering college I took a job  in 1957 doing computer engineering; vacuum tubes and drum memory. Started in real-time system design in 1962. Then .......

   

But I need to stay somewhat on topic.

   

My project is centered on the heat pump area. Installed a OEM earth coupled heat pump with computerized control. Was disappointed to find that the control was based on doing what the rudimentary systems were doing with only moderate refinements. It was as if the "requirements" document was written by the rudimentary system designers.

   

As an EE you learned oscillators. A heat pump is a closed loop system much like an oscillator. But don't try to make the heat pump oscillate; it will feed liquid refrigerant back into the compressor and lead to its destruction, Much like the Reset scenario in this thread, there are currently compressor designs that will survive liquid feedback to a limited extent. 

   

The answer to feedback has been to run very conservative, tailoring each system at install time to stay well away from a unity gain. And this is done by the installing technician typically during the cooling season by following "rule of thumb" guidelines; heating season changes the operating conditions and a return trip tuneup rarely occurs. And there are always maintenance items with a mechanical system that tilt the operation. The ability to measure deteriating operating conditions, via the Internet, can lead to corrective action before they lead to unplanned outages.

   

Conservative operation means reduced capacity. Reduced capacity means reduced efficiency. A 5 ton heat pump rarely produces 5 tons, sometimes more (usually when it is not too hot or cold out and capacity is not a major concern) and much less when the climate is at extremes. The current answer to this is to design multi-stage units; embedded control can vary capacity without requiring additional hardware that lays fallow most of the time.

   

FPGA. I have a background in computerized message switching systems (1962). Then cross bar switches were used by the Telcos. PSoC3 must use some variety of switching that functions much like the old hardware. Are FPGA's the genisis of the PSoC3 reconfiguration capabilities?

   

Regards,

   

Bruce

0 Likes
Anonymous
Not applicable

 WDT and API calls,

   

My current thinking on avoiding WDT events with their unknown causes. 

   

Do not use synchronous API's that support that feature, use asynchronous calls.

   

Pseudo code to illustrate:

   

WDT "tickle" prior to the API to ensure that we are not on the verge of an WDT event from some other cause.

   

Call the async API.

   

For x times loop:

   

  Test the completion code (with a save) ; if complete or an error, exit For.

   

  Some delay y (x times y should be somewhat longer than the expected completion).

   

  WDT tickle just as a sanity function.

   

End of For.

   

Test the completion/error code and take appropriate action.

   

Any remaining near WDT events should be detected and remediated during testing and debugging by making the WDT a shorter time.

   

Any WDT events occurring during normal running represent a critical condition. 

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

In 1957 I was ripping apart TVs, but not sure why, just collecting parts. That

   

started my career.

   

 

   

I picked up a drum memory in a surplus joint early 70's, was going to try and

   

build an interface, never got around to doing it. I was building DTL/TTL based

   

music synthsizers at the time. As a production EE on a PMOS line at NSC in

   

early to mid 70's we were manufacturing serial shift registers as drum replacement.

   

1Kb units. Then we had a contract with DARPA (if memory serves me) for a

   

256Kb bit shift register, 1 die /wafer, 2" wafers I think. Yield was 1/2 die / wafer,

   

we got one good part every 2 wafers on average. Registers maxed out at ~ 1 Mhz

   

clocking, 15 volt clock, a hybrid bipolar clock as Cload was sum off all bits gate

   

capacitance, no clock tree, and of course miller effects in the transition.

   

 

   

First processor I used was 1972 in school, Intel gave them a 4004 and I was the only one

   

in class that knew how to solder, build stuff. Not quite true but close. Toggled switches

   

to get it to run, in single step arrangement. When I first got part and manual I sat at home

   

in easy chair trying to figure out what good was a processor, and finally the light bulb went

   

off after several days (I am slow). It was a true revelation for me.

   

 

   

Sounds like your early contact with mainframes pretty fascinating.

   

 

   

Mid 70's I became a test EE, wrote PDP8 code, paper tape on a TTY, and Teradyne tester

   

code. Later Sentry. Later we had a need to work in ASM, they had no manual for that.

   

So I wrote test vectors for the machine and slowly figured out what it would do. Real ugly.

   

I also used FORTRAN on a mainframe (cannot remember what it was) to evaluate process

   

and test flow yield issues. Boss kept dinging me for spending time on machione until I

   

got enough data evaluated to show line was losing needlessly ~ 50% of its revenue and

   

problem was a specific tester. Going forward Boss left me alone to do my thing. I am sure

   

we all have had similiar experiences.

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Are FPGA's the genisis of the PSoC3 reconfiguration capabilities?

   

 

   

Yes. late 70's, early 80's there were divergent paths on analog and digital in

   

single chip designs. But CMOS brought this together along with underlying

   

ASIC activity and bridge processes that could effect analog.

   

 

   

Back to reset problem, WDTs are OK as a mechanism to find run amok CPUs,

   

but not the total solution. Too bad the PSOC 3 does not have any trap capability,

   

like exists in some ARM cores. The M3 core, like PSOC 5LP does have some

   

traps. This all leads to issues surrounding non stop computing. I tried at one

   

point to find NASA docs on this but had no avail.

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

@The Oldie Club

   

Funny to see that we have some similarities in our lifes. In 1962 (I was 13 years old) I bought my first two transistors (OC71/OC72). A few years later I started my education at BAYER and studied chemistry. Later I started my second education at a nuklear research center and came in contact with a IBM360/IBM370 coupling, some PDPs, an analog calculator and a paper-punch programmable computer for the neutron-activation analysis. I learnt a handfull (rather two) programming languages, some assemblers, worked for a government project in a hospital and at the time AMD introduced their 16-bit processor I went to a distributor as FAE introducing the so-called "Development Systems". About 20 years ago I started my own 1-man company which helped me survive the mis-managed distributor.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Dana,

   

While working on a RTC fix, my mind suddenly recalled something that could apply to WDT events. Funny how the brain keeps working on something while you are  occupied on something else.

   

Many years ago while at IBM, I was involved in the development of a new communications system. On one visit with the engineers, they sparked my interest with performance engineering (the PE portion of my current company name). They built a digital to analog device which had as its input the Program Counter of an existing system and the output was coupled to a modified scope as the horizontal amplifier input. Running the system and observing the scope in dim light revealed the address ranges that ocupied the most time (scope intensity and persistance made this obvious).  The process of obtaining and returning memory was consuming about 10% of the capacity. So they had designed a new pair of hardware assisted instructions which they demonstrated as cutting the overhead by an order of magnitude. They called the new "register" the Next Available Block Register which many years later I still remember as the NABR.

   

A NABR would assist in finding potential WDT areas of interest. Maybe not possible to implement and probably out of reach of most PSoC developers. 

   

Could the DMA be used to sample the PSoC Program Counter and produce an output stream? Some post Histogram process would be necessary to find areas consuming a large portion of the capacity and thus be the most likely source of WDT events. Or provide clues as to where to spend more development time to improve the design. A useful development tool.

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I like the idea, very elegant, relatively non intrusive. I would think just

   

setting up DMA to VDAC might be a starting point.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

The 64k Flash on the kit chip would require a 16 bit DAC to get 1 address bit resolution. Even 2 bit resolution would be sufficient to get results that could map to the address warranting further review. If a DAC  is used, its tolerance adds to the ambiguity.

   

The VDAC is 8 bit DAC component with an external integrating capacitor. Conceptually it requires a periodic input to produce an equivalent maximum 12 bit DAC. The integration requires some variable time to settle.  The Progam Counter is a monitonic progression with quantum changes due to calls. Not suited to feeding a PSoC3 VDAC.

   

This is what led me to suggest feeding a DMA a sampling of the Program Counter and outputing it to an external data stream. The sample rate need not be at the master clock rate; a longer running test should catch the high MCU usage more than the low MCU usages areas. And most code is dependent on the functions that run which could also be not periodic. I think this requires a intermittant DMA; both for the single Program Counter memory address as input, and for the sample rate. The MCU should only be used to set up the initial DMA; would not want the DMA to be reflected in the output data stream.

   

A 16 bit DAC is a tall order even if it could be coupled to the Program Counter. External data reduction with a PC seems to be the way to go, initially producing a Histogram and an address "hit" table in descending order with selective low order bit truncation. It is probably not necessary to program a read of the .map to find the names of the Call areas; only requires a sorted .map in address sequence and a little manual effort.

   

Anybody familar with a DMA and/or external data stream output that can add to this discussion?

   

Thanks,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

How about an X-Y display, upper 8 bits go to Y VDAC, lower 8 to X VDAC ?

   

 

   

Of course that does not handle speed issue, result would be a form of integration I

   

would think. IDACs are faster by ~ 8 X, very usable with a scope. Still thats a couple

   

hundred nS.

   

 

   

Just a thought.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

The X-Y is an ingenious thought. A possibility well worth exploring.

   

I think 2 plain vanilla DAC's would be the choice.

   

Since the Program Counter uses 2 SRAM bytes, the separation into X and Y is almost too simple. Serendipity strikes again!

   

The is a caveat about a reading the Program Counter only when the MCU is stopped (think Debug), it may not apply to a DMA read of a special 2 bytes of SRAM. There exists some hardware function for the normal PC incrementing and timimg (think addition carry propogation accross the 2 bytes) and it may be the reason for the caveat. Don't know if the incrementing introduces X-Y noise, the DMA could possibly see a partially incremented PC. And it would be necessary to synchronize the 2 DMA's.

   

Don't know about speed. But since this is a sampling technique, the consequence of "slow" speed may only equate to needing to run the test for a longer time. Real-time viewing may require a high persistance scope. And a scope with accessable Horizontal input. My current XYZ analog scope does not have a horizontal input; X and Y are vertical inputs, and Z is an intensity modulator input.

   

The scope picture that results is not quite clear to me. The Y component represents 256 levels, as does the Z level. What results probably looks like a TV no-signal snow screen. My project only uses ~32K of Flash so only the bottom half of the screen would show snow. Using the intensity control to delineate the heavy vs. light MCU usage is most likely necessary, thus I think an analog scope is necessary. However the DSO Voltage readout is a definite advantage if the analog scope shows where to look for voltage readouts; complicated possibly by the fact that the analog scope is a "flickering" dynamic display. Screen interpretation may be more of an analog "art" as compared to the digital output stream that I suggested.  

   

There is a definite requirement to keep this a simple as possible if it is to become practical. Since I don't know the cost and complexity of external data stream capture, I can't currently compare the two possibilities.

   

Thanks,

   

Bruce

0 Likes
Anonymous
Not applicable

 Dana,

   

My scope does have an X-Y position on the time base selector. Used for Lissajous figures and maybe this reason. Forgot about it until I dug out the manual.

   

Bruce

0 Likes
Anonymous
Not applicable

 Dana,

   

Took a quick look at IDAC8 documentation. X-Y feed serendipity just came apart. There is only 1 DAC Bus. I think this rules ot 2 DMA's feeding 2 IDAC8's.

   

An IDAC8 Register feed can be on the register value changing (does the IDAC8 think the 2 byte PC is 1 register or 2 independent registers?). This may result in X-Y bifurcation but I am not sure if this is detrimental. So what if the Y IDAC8 is changing less frequently than the X.

   

Errata on a previous post on screen views: Z should read Y.

   

If you have some IDAC8 code examples, please post them. Register input examples would be more valuable.

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

A capable DSO can do a color graded map on frequency of hits. We

   

could use a timer to trigger the DMA, a substitute for sweep control in

   

scope. Basically control sampling rate of the PC.

   

 

   

May have to chain the DMAs to get both VDACs loaded.

   

 

   

The below is legit.

   

 

   

Regards, Dana.

   

 

   

0 Likes
Anonymous
Not applicable

 Dana,

   

A capable DSO surely would simplify the viewing and measuring problem. But it introduces a "pocketbook problem" to me. I can't find that feature with my new Hantek DSO5102BM scope.

   

The legit reference; was there supposed to be a file enclosed? Nice IDAC8 pictures though.

   

Thanks,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

"Legit", just referring to the fact you can have multiple IDACs each with their

   

own address and individual analog outputs.

   

 

   

You do have persistence in that scope, maybe not color graduated though.

   

Still the most useful mode to have in a scope. The color graded is a "nice to

   

have, not used very often" feature.

   

 

   

Infinite persistence is super useful looking at power supply rails for total noise.

   

Just hang your probe on a rail, punch up infinite persistence, and watch the pk to pk

   

nosie accumulate on the scope.

   

 

   

Regards, Dana.

   

 

   

0 Likes
Anonymous
Not applicable

 Dana,

   

Intensity applies to all dots/lines without any frequency of "hits" modulation.

   

Persist also applies to all dots and a represents a duration rather than a fading type of CRT phospher. The subtle name difference does not lead a new user to recognize the difference until you break out the manual. Can't even do a Find on persistance.

   

Neither helps in this application.

   

Infinite application you describe, I hope I can remember that trick when I need it.

   

Are you indicating that the 1 DAC Bus is not a problem for this use?

   

Thanks,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The persistence will not give us frequency of hits, but it will

   

give us a map of hits and will persist on screen. So the map

   

will build over time and stay 'lit". Ultimately we will capture all

   

addresses that occured in PC. If we set persistance to < infinite

   

then we can look at, in a ugly way, frequency of hits, as those

   

less frequent will persist less on the display. They will be darker

   

in appearance.

   

 

   

Or if we run a timer to trigger the DMA, we then control the sampling

   

rate of the PC, and hence effect somewhat the same result. Or so

   

I think.

   

 

   

Where do you find there is only a one DAC buss ?

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

1 DAC Bus from the Creator 3.0 SP2 IDAC8 component description. Cautions as a result are documented but I did not spend the time to fully appreciate the statement implications.

   

I respectfully disagree with a DSO showing dimmer dots. The 8 bits representing a dot are ADC voltage related producing either X or Y screen position values. There are no DSO bits to represent luminance values.

   

This is unlike a PC monitor where the RGB color values represent their respective luminance; i.e., equal RGB values yield a Black to White via a shades of Grey transition (0,0,0 to 255,255,255).

   

If you were to set the DSO Persist to 0.2 seconds and some code runs into a tight loop that is greater than 0.2 seconds, then at the end of 0.2 seconds the only remaining dots are from the loop addresses. Any other dots lit at the start of the loop will extinguish as their 0.2 seconds Persist duration expires. They will go from fully lit to fully off as a step function and not as a gradual extinguish function. Clumping of older dots will present a pseudo dimming effect as one by one their dots extinguish, because the eye sees a pattern of dots rather than a collection of discernable individual dots. Any appearance to an observer that differs from this will be as a result of persistance of the human eye; movies and TV take advantage of eye persistance to be able to see without flicker around 16 frames a second and higher.

   

The DSO MCU has its hands full applying Persist to individual dots. All the while continuing capturing new points and all else that it does. I suspect it is maintaining  multiple screens on a rotary basis, displaying the oldest while computing the newest. I would not be surprised to find that Persist limits memory depth when not off or infinite.

   

Regards,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Take a look at this -

   

 

   

www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm

   

 www.google.com/url

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

Interesting links.

   

Last night I realized that my rotary Persist computation schema should be more likely "Displaying the current while also filling the future screens", The number of future screens is a function of frame rate and Persist duration. They automatically drop off the display if they were not subsequently active. This eliminates any computation on a dot by dot basis which was initially blowing my mind. The Tektronix link gives more detail to this process under the "4" banner. I guess my thoughts on this technique are no longer patentable!!

   

The capable DSO which both links show makes my generic reference to DSO should be My DSO. Boy, color sure adds gobs of memory. And the Tektronics link shows that true CRT persistence is hard to acheive with a DSO mostly because of non-linear reasons.

   

Still thinking about what the XY screen will look like and how to map it to an area of code.

   

Regards,

   

Bruce

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

In a sense its inherently mapped vis a v the fact that its a reflection

   

of what the PC is looking at. Max address is upper right hand corner,

   

min address is lower left. Of course you can always fool around with

   

layout/addressing to create different formats.

   

 

   

With some interp code you could potentially map and place a symbol

   

for specific f( ) areas.

   

 

   

In so far as color DSO, prices falling like a stone as they are all based on TFT,

   

inherently built with a triad pixel arrangement. Using it is another matter, at acquisition

   

speeds that is. But then thats the rub, DSOs show you what has been processed

   

after the record acquired, lends itself to all kinds of non real time measurements.

   

 

   

I have a full 1 G analog scope, and once in a while I dig it out to see whats actually going

   

on. One of the downside of samplers and all that post processing in DSOs. But then

   

this is a discussion for a whole other day. If you really want to know about analog signal

   

follow the Yahoo Tek Group, or the LeCroy group. I will bet Marconi has a similiar group.

   

Those guys know stuff I will never know.

   

 

   

There was a guy living in his home, lab in dirt basement, ~ $250K of equipment, and on East Coast

   

he was the goto guy for 40G and above phy and PCB work. I called on him multiple times (not enough

   

I may add) and learned I was still in kindegarten every visit. Many of the 40G guys out here ex raytheon

   

radar. They used this guy. He knew what waves and materials were going to do intuitively. Awesome stuff.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

Looking at my Hantek DSO X-Y display leaves me wondering if screen interpretation is going to be a stumbling block. A checkerboard. Consecutive addresses will wrap from one side of the display to the other when crossing 256 boundaries. And the display is fairly small for these tired old eyes. And that assumes that "persistence" is discernable.

   

I am still inclined to use the DMA to get the actual addresses off the board and into my Personal Computer. I think I have a straight forward way to accomplish that goal.

   

A 16 bit DMA TD chained to itself that reads the 2 byte PSoC3 PC. Probably Strobed on a rising sample clock maybe around 32K.

   

The DMA feeds a 16 bit Shift Register that produces a serial output.

   

Both new components for my project. The following already exist.

   

The Shift register feeds a UART that feeds a BlueTooth Module that streams the data to a BlueTooth module on my PC USB. 

   

A VB.Net PC program with a Serial Port definition is needed but I already have the Serial Port code as a result of the Data Acquisition reporting in my surrent project. Just a SMOP (Simple Matter Of Programming that never is easily realized.)

   

What do you think of this "Stroke of Genious"?

   

Whoops, I think I just broke my arm while patting myself on the back,

   

Bruce

0 Likes