Reset Recovery Considerations

[Anonymous]

 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

[ETRO_SSN583]

Needless to say time to create a test case. I will try to

   

get to it over the next few days.

       

Regards, Dana.

[Anonymous]

 Dana,

   

A commentary if I may.

   

I was a project engineer back in 1964 - 1965 developing a real-time communications computer for the commercial market that featured a 16 x 16 interrupt system; a total of 256 recognizable interrupts. The entire interrupt was handled with hardware. Each of the top 16 levels had dedicated memory for storing the essential items to be able to return to the interrupted state. And when an interrupt routine was finished all that was necessary was to perform a Jump to a special address where all of the restorative efforts were handled by hardware. The interrupt hardware was not more costly than a single 4096 word x 16 bit 1 microsecond magnetic core memory system (State of the memory art at the time).

   

Most of the digital world was still using punch cards or paper tape and other "modern" things in that era.

   

Here we are in 2014 and there are such arcane things like "Stack, PUSH, and POP". Yet we can build chips with GOO-Billions of semiconductors and sell them for only a few bucks.

   

When is the MCU going to get a face-lift?

   

It is long overdue.

   

Thanks for letting me "vent",

   

Bruce

[ETRO_SSN583]

My vent is where are the traps for modern processors ? For non stop

   

computing, watchdogs only part of the solution. And why are we still

   

fooling around with assymetrical non linear architectures. Most of

   

these issues well understood in 70's, I am sure the mainframe guys

   

would tell me 60's. Why, if a 10/100 mac only needs 10K gates, do we

   

not have emacs on 50 cent parts now ?

       

Don't get me started.....:)

       

Take your pill Dana.

       

Regards, Dana.

[Anonymous]

 Dana,

   

I am pretty sure I found the source of my Resets.

   

It is the Motor Speed control on an ancillary piece of equipment. It uses a chopped Triac control, probably with a chop frequency around 100KHz (of cource it will vary).

   

The reason it was "eliminated" from a cause was that I just bypassed the speed control and did not remove it from its power source. When the power source was turned on, the control still ran its chopper even though there was no usage of the output. It was still producing the RFI/EMI.

   

Went to running the induction motor at full speed, and unplugged the speed control.

   

14 days without a reset! 

   

Hooray!,

   

I still think it prudent to be able to survive resets.

   

Does "asymmetrical non linear architecture" refer to multi-core (multi-proccessing)?

   

Bruce

[ETRO_SSN583]

asymmetrical non linear architecture

       

Basically not a memory mapped core where all RAM, EE, FLASH, Register

   

is not in the same address space. So the instruction set does not have

   

qualifications to it on what areas it can operate on.

       

Thats a linear architecture.

       

Regards, Dana.

[Anonymous]

 Dana,

   

OK, but isn't that a result of Byte oriented (Commercial in IBM terms) or a small word (Scientific) architecture?

   

Most of my past has dealt with word oriented instruction CPU's. If the word was large enough, an instruction could have sufficient addressing capability to not need to play all the games to be able to address without modifiers. Worked with both types, agree without is superior.

   

But it is not all bad. The American Airlines/IBM SABRE project was running out of memory addressing with its 7090 CPU, a critical problem. A very savvy Senior IBM tech went home one weekend and conjured up an answer (early 1960's). There was sufficient time between a memory address build and a memory address read/write to insert a small register; adding this provided a way for adding memory if a user added a SET BANK instruction which loaded the new register. I am not positive, but I think this was the beginning of virtual memory. It was successful and the IBM'er was rewarded with becoming the first Consulting System Engineer and a raise to accompany it.

   

Regards,

   

Bruce

[ETRO_SSN583]

Thge 4004 was 12 bit addressing, 8008 14 bit with its HL register, and 8080 full 16 bit.

       

There were some RISC machines where addressing width was close to accum with as well.

       

One varient, Scamp, NSC, had a PC in which you could do math with an offset w/o having to

   

use accum. So you could actually use the adressing register as a multiplier. It led to some

   

pretty simple coding for some problems that otherwise took soft code to implement multiplier.

       

In any event the accum  width (historically accum classified machine) was not the consideration

   

for addressing, simply die size ruled.

       

Sad we do not have the design team history of many of these decisions, I would bet I could

   

still learn a lot from those meetings.

       

Regards, Dana.

[Anonymous]

 Dana,

   

Merry Christmas if that is appropriate.

       

Debug on-Chip. From the PSoC3 Architecture Manual:

   

PSoC® 3 debug modules consist of the Debug on-Chip (DOC) and the single wire viewer (SWV). The DOC interfaces

   

between the CPU and the Test Controller (TC). It is used to debug and trace code execution and to troubleshoot device configuration.

   

The DoC exists only on the 8051-based PSoC 3 family.

   

The SWV module allows target resident code to communicate diagnostic information to the outside world through a single pin.

   

Usage examples include data monitoring, viewing OS task switches, printf debugging, and call graph profiling.

       

and call graph profiling

       

Was this overlooked?

   

Cheers,

   

Bruce

[Anonymous]

 Dana,

   

The SWV output is too fast for my Bluetooth. Needs something probably higher $$.

       

But I changed to feeding an VDAC8 with a _SetValue whenever I made a Call (als callName).

   

My project has a 1 Second DAQ and my DSO shows a great result. The DAQ portion is taking only a small portion of the MCU each second.

   

DSO pic attached.

   

Regards,

   

Bruce

[Anonymous]

Dana,

       

A more detailed look at the DAQ time breakdown.

       

Here I added the ADC DelSig _StartConvert to _StopConvert feed to the VDAC8.

       

The DSO only shows the expanded DAQ  plus a little bit more. The upper portion of the DAQ are the Convertion times, while the lower is user code to process each measurement.

       

You will notice not that all measurements require the same user code time; if there is an unusually long user time, the measurement in question can be plainly seen and remedial action can be pinpointed.

       

It is quickly becoming an "enchanted" tool for me!

       

Regards,

   

Bruce

[ETRO_SSN583]

Very interesting. I am still waiting on ARM access to PC response

   

from Cypress.

       

Regards, Dana.

[Anonymous]

 Dana,

   

When I first looked at the VDAC8 output, I thought that there were a lot of artifacts.

   

But after studying them, I realized what level of detail the "artifacts" were really showing.

   

The DAQ uses the ADC DelSig Turbo because I was seeing a lot of jitter. I have Turbo set to seven (a Prime number). And when this still showed jitter, I went to running the conversion five times with a user coded average.

   

So the "artifacts" are really showing what I actually coded. Each input shows five somewhat long ADC conversions with a small amount of user code to run the conversion loop.

   

Back before the Reset saga, certain of the conversions were still showing jitter; the pressure transducer was still showing pulses. So I added exponential averaging with each input having its own exponential average period control. With the PC reporting including feeding Interop EXCEL, I produce a graph. Looking at the graph allowed analysis of the averaging to see where it might be excessive. The graph was originally done to find the interdependency of all of the variables I measure; a by-product of the closed loop system I am trying to control.

   

The system has three primary functions; Data Acquisition, Control, and reporting via BlueTooth. I chose CallName ENUMs so as to delineate these three.

   

The reporting via UART BlueTooth indicates what is a prime case of non-optimized code. It uses the UART _PutArray API. Attached is a DSO screen with a measurement of the _PutArray; the reporting is almost entirely the _PutArray and this with an array size of only 56 bytes. The ENUM snippet:  BT_UART_PutArray_CN=44,    and at 16 mv yields 704 mv.

   

I am about to try to measure the Control, but at the bench it will be somewhat artificial. Th current Control DSO is the middle stairstep display and is pure overhead (mostly sanity type coding) without any control functions being called.

   

Regards,

   

Bruce

   

[ETRO_SSN583]

I got back the reply from tech support.

       

For the ARM one simply types this before main( ) and the

   

variable will always hold a copy of PC -

       

register int data_unsat asm("pc");

       

PSOC 5LP, must be the debugging HW that is used.

       

I have not done any further yet with it, eg. the x y display, will try to get to it soon.

       

Regards, Dana.

[Anonymous]

 Dana,

   

The 5LP seems to have more acessability to some otherwise "non-user" things than the PSoC3. Good news.

   

The speed of the 5LP vs. the DMA speed may lead to getting two bytes of the PC that are not a snapshot. That is the upper byte may not be the correct byte to match with the lower bytes when a 256 boundary transition occurs.

   

Example:

   

0x1FF may be read by the DMA as 0x2FF if the PC is faster than the DMA. X-Y will show an artifact if this happens, but it should always be at the FF side of the high order byte display. The 00 side of the high order byte will be lacking an entry that has been attributed to the split.

   

Something to watch for, or something to ensure it is not happening. May be difficult to ascertain. The number of bytes per instruction may cause a even byte instruction boundary that prevents this from happening.

   

I am still refining the PSoC3 VDAC8 DSO display. I find that adding a small CyDelayUs(x) helps the DSO viewing in certain cases where a call causes a quick secondary call; small enough to not cause problems. 

   

Regards and Happy New Year,

   

Bruce

[Bob_Marlowe]

The PSoC5 has got an ARM Cortex M3 core which is a 32-bit machine.

   

So there are no "Snapshots" expected as opposed to the PSoC3 as long as you use nothing larger than an int32. Intermediate results are kept in register or on the stack.

       

Bob

[ETRO_SSN583]

Bruce, I have another question into tech support on how the

   

capture actually works. I think it is the debug HW being used,

   

and so the snapshot is accurate, its a HW copy of the PC

   

being done.

       

Stay tuned, Dana.

[Anonymous]

 Bob,

   

I thought at one time that I might have to go to the 5LP.

   

But now that I am mapping the PSoC3 calls, I find that I am only spending ~24 MilliSeconds doing the 15 ADC measurements with conversion to native units (Temps, Pressure, etc.). Preliminary Control function measurements show even less time, more exact live measurement is still to come. Communicating to the PC VB.Net program at less than 2 MilliSeconds (almost entirely the _PutArray to the UART). With 42.6K of flash used, I was expecting a heavier loaded MCU.

   

Having worked with Real-Time systems since about 1963, I code with CPU usage in mind; writing efficient code such as binary searching rather than linear searches, using formulas rather than searches where posible. But I was not expecting the PSoC3 to exhibit the ability to support the workload that I put on it and still have much excess capacity. 

   

PSoC3 Flash size seems to be a weak point. Back in my days at IBM, we were not allowed to propose a system unless the peripherals were up to the task of reaching a fully loaded CPU. And the CPU had to support at least a doubling of the workload. Some RPQ peripherals were designed, but rarely built, that would achieve what was in the pipeline. A customer could agree, in writing, to overriding the limitation. There is always a consideration that the PSoC 5LP is a logical stepup; migration from PSoC3 to PSoC 5LP is not quite as easy as I would like, so the 5LP is the better starting place if future capacity is an issue.

   

I could run the Master Clock from 24 MHz down to some low value and still not tax the PSoC3 MCU.

   

What is the 5LP designed to handle?

   

Is it capable of true C++ with all of its benefits? I sure do miss working in C++.

   

Regards,

   

Bruce

[Bob_Marlowe]

@bruce

   

Although off-topic: C++ is a strong demand from most developers and can be implemented on an ARM M0 or M3 core. Since this feature was strongly demanded at Cypress's Customer Advisory Board (CAB) I am quite sure that one of the next software improvements will be related to C++.

   

The architecture of PSoC3's 8051 is comparably "old", but many developers know about it and find it easy to use something "well-known" although the use of C-language has a level of abstraction that can make it indifferent which core lies behind the surface. Imho even the PSoC4's M0 core is "mightier" in terms of "faster" than the PSoC3's core. I admit the assembly-language for ARMs can be more complicated, but mostly because you have to keep track of the usage of so many registers.

   

As many other ARM implementations show, C++ can be adapted easily.

   

You address flash-size. Since PSoCs are controllers the job they do is mostly limited, compiling a project wit optimization switched on using Creator 3.0 will save usually more than 30% of code-space (3.1 already required less space without optimization). When we talk about the good-old-IBM-Times I can remember that an I/O channel usually has quite fewer code-space than one of the PSoC5s (Yes, I started with an IBM 360).

       

Bob

[Anonymous]

 Bob,

   

Having spent most of my computer career in capacity planning issues, I overlooked something that is new to me.

   

Power. The PSoC3 with its high maximum speed, has enough capacity at reduced clock speed to conserve power. Better suited to battery powered applications.

   

I wonder what the tradeoff between running at high speed and then sleeping, versus running at a lower speed without sleeping. Has any analysis been done on that?

   

Still learning after all these many years,

   

Bruce

[ETRO_SSN583]

The sleep vs low speed, application dependent. If code at low speed is fractional part

   

of time clearly one would lean towards sleep. Stating the obvious. The faster that clock

   

runs the more gain can be had sleeping in that case. The clock can be run down to DC,

   

but of course any switch cap HW would be toast.

               

http://www.cypress.com/?rID=64554     AN77900 - PSoC® 3 and PSoC 5LP Low-power Modes and Power Reduction Techniques

   

http://www.cypress.com/?rID=43337     AN61290 - PSoC^® 3 and PSoC 5LP Hardware Design Considerations

   

http://www.cypress.com/?rID=78797     AN86233 - PSoC® 4 Low-Power Modes and Power Reduction Techniques

   

http://www.cypress.com/?rID=96072     AN90114 - PSoC® 4000 Family Low-Power System Design Techniques

           

Regards, Dana.