PSoC™ 5, 3 & 1 Forum Discussions

 This Subject summarizes the voluminous “Reset Recovery Considerations” Posts.

I am writing this as a benefit to others, and also for myself since the recap effort refreshes the points in my mind.     

The premise is to find ways to deal with resets that occur. Prevention of resets should also be made where possible. The cost of prevention can be high, particularly with environmental EMI caused resets, some of which may be in equipment not related to the embedded system.     

A Watchdog Reset can be just as disruptive as the other resets; development testing should explore how close to the WDT threshold you are, with remedial efforts applied when the “cushion” is too low. A production system WDT event recovery is a user consideration; does it represent a solid failure or just a single occurrence. CyResetStatus is useful to report WDT events.     

In the process of analysis of resets, a technique was developed to find where in code a reset was occurring. A byproduct was to be able to find those areas of code that were heavy consumers of MCU capacity. The technique is discussed below.     

Resets fall into two supersets. Some existing documents contain misstatements.  From Cypress Tech Support:     

- “Software reset and watchdog reset fall under soft reset sources.”          

- “XRES, IPOR, PRES, LVI and HVI sources fall under hard reset sources.”          

Only Soft resets are reported via CyResetStatus.  WDT implementation is counter intuitive in that it is a soft reset.          

 LVI, as a hard reset source, can be specified to produce either a reset or an interrupt (which has user code insertion spots).  The choice should be obvious.          

Reset recovery should be tempered as to whether it represents an unrecoverable event (power supply failure), or a transient condition (EMI, Power Failure without backup power).     

Reset recovery has the objective of restoring the system to the state where it was when a reset occurred while reducing the time of the outage. Critical systems may need some variety of backups. While a recovery is underway, some means is required to prevent making interim actions effective until the recovery is complete.     

I use the 32K external crystal for an external clock for accurately timing components and producing a DIY RTC. The startup time for the 32K oscillator is a consideration. I am exploring using an external RTC Module with a small coin battery backup. A configurable square wave output is available for use within PSoC3 (may need synchronizing). Having a battery backup makes the RTC always available and oscillator startup delay is eliminated.     

While it is possible to control components without saving their control parameters, it should be discouraged. The current value of these is the key to quickly return the system to the state  when the reset occurred. The use of EEPROM is not a viable answer due to duty cycle and to its large but limited lifetime. The use of SRAM can be the answer, but the default action of a most resets is to Clear SRAM. There is a  .cydwr  System option to not clear SRAM on startup (and resets), which appears to be the desired choice.     

A method of determining if a POR Reset occurred is required. A POR requires establishing the system; otherwise a recovery is the method of choice. But POR is not reported so other detection is required. Examining a configuration SRAM entry could provide the differentiation. I employ a Global, “RUN”, which is used to switch between the backup and PSoC3: if it is set, then PSoC3 has been in control when the reset occurred. This applies to all hard resets; thus recovery is the same.     

Most resets invoke INIT.A51 whose purpose is the restore initialized SRAM variables to their initial value. Initialized component control parameters stored in SRAM would negate being able to use them during recovery. Avoid initialization for recovery sensitive SRAM variables.     

Any dependent SRAM variables would not need to be recalculated because not clearing SRAM would leave them intact. They should not be  initialized as a result of typical coding practices (else INIT.A51 will wipe them out).     

Most resets return components to their DWR settings. There is no option to not do the reconfiguration. Therefore a  recovery task is to return the component settings to SRAM values. One reason why not clearing SRAM is desirable. The component reconfiguration for soft resets is a superset of hard resets; last step for soft is to re-establish the components to their last known state.     

Knowing where in code a reset occurred may assist in the recovery or remedial action. It may require an additional set of steps. If the “where” included more than one possible action that might cause a reset (i.e., turning  motors  on or off ), then selectively inserting a digital output pin instruction, that is used as a DSO trigger, allows finding which of the actions is causing the reset. GlobalSignalRef might assist this by providing a signal rather than an instruction, but interpreting it based on time is more of an art.     

The technique alluded to above was initially developed with “where” as the goal, but has evolved into a twofold purpose. The second purpose was to be able to statistically determine the heavy MCU users. I refer to the technique as CallName logging/sampling. It uses ENUM ordinal entries of the CallNames (with a suffix to make the compiler happy) and those calls of interest being prefixed with the “suffixed CallName” saved to a Global and a post call to restore the Global to the name of the caller. The Global thus contains the name of the called routine during its execution, and being restored at the completion. If the calling routine is not of sufficient interest, the post call could restore the Global to a “not of interest” indicator, zero fills the bill). The Global is only available after a reset if SRAM is not cleared and the Global is not initialized. If you decide to retain Clear SRAM, it would require Generated Code modifications to retain the Global (a Case has been entered to request such mods including Generated Code as possible participant).      

Statistically sampling of CallNames; by using DMA, it is possible to sample the CallName Global with a destination of one of two places. An IDAC8 can be used with its output to an analog output pin; an analog scope monitoring the pin would show, via intensity, where most time is being spent. A 1 byte CallName Global output (limited to 256 values) should be discrete enough to see individually on the scope. If an “off board” communication link is available, then a UART (or other link) destination allows for a data stream for a PC analysis to produce a histogram and a usage ranking output. If the PC program were to also read and parse the CallName ENUM, the outputs could be more user-friendly.  DMA sampling frequency will need some empirical testing  to give useful results. If the UART is the method of choice, I recommend “wading” though the original Posts to learn a simplified DMA UART methodology (it will be found in Page 3).     

AN60630 shows ways to optimize PSoC3, an excellent reference.  However, it is time and co$t intensive to apply the optimization to all portions of a project. The old 80/20 rule says find that 20% of the code which consumes 80% of the capacity and your development Dollar$ will be reduced doing optimization. CallName sampling can show statistically which of the calls are consuming the most capacity. Optimize the worst and work downward until the co$t vs. reward says stop.     

Resets understanding has been a long road to travel but with the welcome help of other Forum contributors; sometimes just asking a question can lead to analyzing an area that might not be considered.     

 Now I need to apply these guidelines retroactively to my project.     

Thanks,     

Bruce     

This is sort of a on going issue for me.

But is anyone having luck printing a float to a LCD using the LCD component.

Ive tried using sprintf and PrintString but only get a blank space....

Application is for Modbus conversion to float32 or Real data type.

I don't have the memory issue that others here have pointed out. Just inability to print a float.

Thanks

This is sort of a on going issue for me.

But is anyone having luck printing a float to a LCD using the LCD component.

Ive tried using sprintf and PrintString but only get a blank space....

Application is for Modbus conversion to float32 or Real data type.

I don't have the memory issue that others here have pointed out. Just inability to print a float.

Thanks

 Bob or Dana,

Do either of you two wise pillars of knowledge have a PSoC1 Eval kit?

I have a strange problem with my current project.

Chris 

Hi there,

can someone please explain the FIFO mechanism behind linked CAN rx mailboxes, please?

I already noticed that there is only one interrupt every Xth message, when X is the FIFO size. Does this mean that I have to handle all messages at once in the interrupt and that the complete FIFO will be replaced when the next interrupt occurs?

If yes, this doesn't really feel like a usual FIFO queue where I usually can pop (get and delete) messages from the front end. Am I using it wrong? Is there maybe some example showing how to do it right?

Thanks in advance!

  I am using CY8CKIT-050 PSoC 5LP development kit, connected to a Windows 8 PC through Full Speed USB 2.0. Can somebody help me in understanding how the 'XferData(buf, bufLen, pktInfos)' API call works for Isochronous IN endpoints?

1. Cypress CyAPI Programmer's Reference manual (2011) mentions on page 8 that the XferData() call is overloaded to take an additional argument 'pktMode'. If pktMode is true, then the partial data transfer is enabled at an IN end point. However, when I used this call for an ISOC IN Endpoint with pktMode = true, then the compiler gives an error saying 'Too many arguments in function call'. Does this parameter valid for ISOC IN EPs? If yes, then how to use 'pktMode' argument in XferData() call for ISOC IN EP?

2. I have configured an ISOC IN EP with maximum packet size of 1023 bytes and DMA transfer with Automatic Memory Management. I have set the end point transfer size for this EP as 8184 bytes (8 times 1023) using SetXferSize() call. Now, while using 'XferData(buf, bufLen, pktInfos)' API call with this EP in host application:

(i) Should the buffer ('buf') size, and 'bufLen' value be always 8184 bytes (8 times 1023)? Or, should the  'bufLen' value must be equal to maximum packet size (1023)?

(ii) Can we use 'bufLen' value less than 8184, while keeping the buffer size still to be 8184 (For example, in cases when we want to receive less than 8184 bytes)?

(CyAPI manual says that bufLen should be 8 times the maximum packet size, but  I suspect that I am receiving excess data in host application on doing so.)

 Has anyone here tried a bootloader from Android via Bluetooth or wifi?

I am assuming if I use SPP that I can just set up serial port bootloader and the program doesn't care that the serial port goes via BT or wifi to the application

Hello every one!!!

 Have any of you tried to program a Schmartboard whit CY8C3866LTI-030?

I need to test a prototype and I do not want to use the CY8CKIT-030 and have decide to buy a Schmartboard.

I cannot figure out how to download the bootloader project  in such a  board using the Miniprog3 kit.

The application note PSoC® 3 and PSoC 5LP I2C Bootloader  ( AN 60317) explain how to download a bootloadable project using Miniprog 3. It assume that you have a bootloader project already downloaded into the Psoc device, in this case, the CY8C3866LTI-030 on Scmarboard.

In summary, may be someone can explain me how to download a Bootloader project in the Scmarboard sponsored By Cypress.

The readme file provided for Scmarborads, explaning how to program the board is not very explanatory for me.

I have attached the Readme file.

I will appreciate  a lot your help.

Thank you very much.