View previous topic :: View next topic |
Author |
Message |
rald
Joined: 04 Sep 2013 Posts: 25
|
taximeter issue |
Posted: Tue Aug 22, 2017 11:15 pm |
|
|
Hello experts,
I made a taximeter but this one is presenting random issues.
Randomly the device gets stuck and does not run. I have been thinking to use WDT interruption but if I use it, the device will reset and I will lose the information.
Does anyone have any ideas or suggestions to prevent this stucking or losing information if device is reset ?
Thanks. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Wed Aug 23, 2017 2:59 am |
|
|
Look at this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=56442>
and this older one:
<http://www.ccsinfo.com/forum/viewtopic.php?t=43358&highlight=watchdog+variables>
Declare global variables as non static, declare local variables without initialisation, and then initialise these yourself when the restart cause is 'NORMAL_POWER_UP'. Otherwise leave them be, and the values will be retained after a watchdog restart. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Aug 23, 2017 5:56 am |
|
|
You need to locate the source of what is causing the 'getting stuck' problem.
If it's a code issue then what Mr T. says is true
but
if the problem is EMI or 'electrical noise', it is possible that data stored in the PIC RAM ( variables) may have been altered. That being the case , you'll need a way to verify the data is good.
I wouldn't want to pay $100 for a $10 taxi ride !!
Jay |
|
|
rald
Joined: 04 Sep 2013 Posts: 25
|
|
Posted: Wed Aug 23, 2017 10:13 am |
|
|
hi
Thanks for response.
I am going to check those links, but basically I am seeing that I will lose information if the machine is reset.
I will let you know if I can find something.
Thanks |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Aug 23, 2017 10:35 am |
|
|
hmm.. since this is a 'taximeter', Can I assume you have a Real Time Clock? If so, those like the DS1307 have battery backed CMOS RAM that could be used to store 'vital' data.
It might be an option for you without knowing what your schematic is.
Jay |
|
|
rald
Joined: 04 Sep 2013 Posts: 25
|
|
Posted: Thu Aug 24, 2017 11:55 am |
|
|
hello,
I discovered that my problem was with the clock (crystal) this was not for high temperature which create that issue, I changed it for internal oscillator which is 8MHz.
Now I have other question, is there any function/instruction that can show me the error? for example I know that we can use WDT to show a message with error. Ss there anything like that but for internal memory ?
Thanks. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Thu Aug 24, 2017 2:35 pm |
|
|
Not too sure what you mean about an internal memory error, but if you mean say a byte of RAM ( internal memory ) is supposed to have 0x27 in it but now it has 0x33, I'd say no.
You could however use CRC and save the data with the checksum. That would give you some level of confidence the data is correct.
It's one reason I use the NVRAM in the RTC chip. It's robust and secure without having to do anything. It is limited to 56 bytes though.
The program memory ( EEPROM) is very robust and unlikely to be changed.
The data memory (EEPROM) needs a LOT of things happen before it can be altered, so it's 'secure'.
A better explanation of your problem, design, operating parameters could shed light on possible options though.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Fri Aug 25, 2017 1:29 am |
|
|
Multiple levels:
First you need to ruggedise your hardware. If you have a temperature problem with a crystal, it implies things are getting quite warm. Look at 'I' rated or even 'M' rated parts. This applies to everything (particularly capacitors an the semiconductors). Remember the internal oscillator is low accuracy (and worse if the temperature range is high). It may well not be adequate if timing requirements are anything other than very loose....
Then if you are suffering from data corruption, then you need to be looking at EMC. Very good PCB design and general layout. The individual memory cells in a chip will give one error in _millions_ of years, if the supply and connections are properly handled (the commonest fault will be cosmic ray changes). I've still got circuits running that have recorded data without error for now something like 30 years....
Then for really high reliability applications, you can look at 'supervisory' designs. So critical numbers are always checksummed for storage, and you have high priority 'supervisory' code that will test these checksums and recover/flag errors. You can even design storage to use Hamming codes, or a combination of these and checksums so you can recover from individual bit errors, but also be aware if recovery is not possible. Rather than his original 7.4 form, 12.8 is much more useful for micro-controller data in general. |
|
|
|