DDRs, config regs etc ever need to be refreshed?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

DDRs, config regs etc ever need to be refreshed?

499 Views
JimDandy
Contributor III

So your micro starts up and runs for YEARS without ever restarting. On startup, various values are written to different config registers etc. What is the mechanism used to hold these values? Are they locked by a bistable flip flop or do they rely on a charge being retained in some miniscule capacitance and therefore perhaps bleed off over a long period of time, causing potentially unreliable operation? (No pun intended :robottongue: )

Labels (1)
0 Kudos
6 Replies

347 Views
rocco
Senior Contributor II

Hi Jim,


Jim Dandy wrote:

So your micro starts up and runs for YEARS without ever restarting. . . . Are they locked by a bistable flip flop or do they rely on a charge being retained  . . .


My two cents:

 

My understanding is that the HC08/S08/S12 families are fully static, in other words, made-up of bistable flip-flops.

 

I'm not sure whether I have had firmware running continuously for years, but I have had systems that ran continuously for months without a restart. I have never refreshed any registers and have never had a problem. Maybe I'm just lucky, but it also may be that the Freescale micros are fully static.

0 Kudos

347 Views
peg
Senior Contributor IV

Hi rocco,

 

I tend to agree with you here.

While I quoted the consensus of opinion previously, I do not actually subscribe to it.

I have never implemented any form of deliberate refreshing.

I have never been aware of any evidence of register corruption over 15 years of product life.

All of our products are industrial and mains powered so "uptimes" are probably weeks/months max.

This poses many questions that we will probably never get proper answers for here.

 

Does Freescale's RAM/registers suffer from any loss of ability to maintain state over time?

Is there any difference in the retention ability of the setup registers over the main RAM.

Is there any reason to suspect that the registers associated with the I/O ports would be more liable to corruption over other registers or the main RAM area?

 

Obviously all products are susceptible to certain events that cause unplanned resetting of the device. Certain measures are usually taken to minimise the chance of this occurring. Is there a window in the magnitude of these events that could cause corruption of RAM/registers but not reset the device (which would reset the registers as well)?

 

 

0 Kudos

347 Views
bigmac
Specialist III

Hello JD,

 

The state of GPIO is controlled by means of flip-flops to provide "static" operation, independent of clock rate.  However, I think that it must be assumed that external interference and noise may potentially corrupt the settings, particularly for those registers more closely associated with the GPIO pins.

 

If the corruption of any register can affect the operation of the end product, the setting should be periodically refreshed.  In this category I would include DDR, and maybe pullup control and drive strength registers.  Typically, I would refresh these on each repetition of the main loop.  Other registers may also need to be considered, depending on the particular project, although any write-once registers would be excluded.

 

The re-initialization of peripherals might also be considered, but would need to be done in such a way that peripheral operations already in progress would not be adversely affected.

 

A further contentious issue concerns the automatic ANSI initialization of global variables at startup, and the period prior to their first read usage.  Some would advocate that automatic initialization should be inhibited, and that explicit initialization should occur closer to the time of first usage.

 

Returning to GPIO considerations, it is sometimes required to emulate an open drain output by flipping the DDR bit between input and output, with a permanently low output state.  Keep in mind that, if any other pin on the same port has its output state altered, when the open drain pin is currently set to input, the "permanent" low state will always flip to high.  Therefore, the output low state should always be refreshed after the pin is set to output.

 

Regards,

Mac

 

0 Kudos

347 Views
JimDandy
Contributor III

Okay. So if I want to refresh THIS_ADDRESS i would try

MOV   THIS_ADDRESS,THIS_ADDRESS

 My assembler doesn't flag an error using this approach. Does it sound valid?

 

0 Kudos

347 Views
peg
Senior Contributor IV

Hello,

 

This does not fix a corrupted register that copying from a mirror in flash memory would.

0 Kudos

347 Views
peg
Senior Contributor IV

Hi Jim,

 

This subject has been touched on here many times.

Yes it is just held in RAM so is liable to corruption over time.

The general consensus seems to be that you should provide some sort of refresh to these registers.

This is especially relevant in small long life battery devices that do not have much of a HMI.

0 Kudos