QY4A Flash as EEPROM COP Bug

[RobG]

I have an application which I'm trying to convert from using an m93c46 eeprom chip for a few bytes of data to using flash as eeprom. No probs with writing the data to flash. The problem is if the flash as ee is used COP reset is a problem.

On startup, the software detects a freshly programmed mcu (or blank m93' when operated that way) and writes a set of default values into flash (or m93'). After that, the software enters the main loop. If the flash as eeprom method is used, the mcu resets due to COP timeout once it enters the main loop. The mcu continues to COP reset even though the flash writing code is not touched on second and subsequent resets.

Cop timeout period is long and main loop is 2.5 ms. COP is serviced at the top of the main loop.

In the main loop, the software monitors supply voltage. If too high, software stays in a loop reading the adc till the voltage returns below limit. That adc loop also services COP. If I wind up the voltage to above the limit to get the program to stay in the adc loop the mcu does not COP reset while in that holding loop. When supply is returned to below limit and program returns to the main loop the COP ceases to timeout. Figure that out! PLEASE!!

The only difference in the software between using external storage and flash as storage is in the initialisation section and there's nothing changed in the main loop (or the adc loop).

Unfortunately I can't use a debugger when operating in the mcu as all I/O are spoken for. I have an MMEVS but that's no use in this case as you can't use flash as eeprom method there.

Sorry for the long winded description but this has me stumped.

Rob

[alex_spotw]

HI:
My guess is that your Flash routines are not clearing the COP, and they are taking longer to execute than the COP Timeout.

You can add a Timer to Clear the COP, or profile the Flash routines to detect where is the longest delay and add COP reset instructions.

Regards,

Alex

[RobG]

Thanks for your thoughts Alex. Trouble is that cop resets during the main loop and not when writing to flash. 

To test if the mcu is behaving as if the cop period is short, I shifted the cop service code to the "wait for output compare" loop at the end of the main loop. This gives maximum period between cop service of abt 0.5 ms. PROBLEM SOLVED. No more cop reset. This suggests that the cop reset period is changed to short. But cop is set in config register for long period????? (coprs=0)

Is it possible that these on chip ROM routines (pgrnge and or erarnge) somehow cause the cop reset period to be changed?  But then how could it be put back to the long period? The config registers are write once only!

Rob

[bigmac]

Hello Rob,

The pgrnge and erarnge routines do not affect the configuration (have a look at AN1831, Rev 3).  I would suggest to reset the COP timer within your initialisation, prior to entering the EEPROM or flash write routine.

What else do you do before entering the main loop?  Are there any delays?  Do you currently write to both the EEPROM and flash sequentially?  If so, do you wait until the EEPROM write process is completed before leaving the routine (this may take a few milliseconds).

A technique I have used with the MMEVS is to use selective assembly (compile) by defining or not defining an EVALMODE label.  During evaluation mode the ROM based routines are bypassed, but I can still test for other problems.

Regards,
Mac

[RobG]

Hi Mac,

It's pointless going on much about when or where cop is serviced since the program runs ok if using eeprom. But suffice to say cop is serviced at the very top of code and several times during initialisation. There is a timer based delay sub used during initialisation. It has a base loop of 1 ms and cop is serviced at top of each loop.

Fact is that if flash routines are called, cop behaves as if the short reset period is set and long if eeprom used. I've tested the coprs bit during execution and it is clear. Also tested srsr register and it is definitely cop reset.

The cop resets occur well away from reading or writing flash based data. There is no problem getting through the initialisation section.

Because of the limitations of the mmevs qblty em, two register files are used. The reading and writing subs test which .inc file is in use to determine if flash or eeprom is to be used. Only one method is used not both. Works a treat. All I do is rem out the inc file not needed before assembly.

The problem is solved by servicing cop in under the short reset period in the main loop (even though mcu is configured for long cop period).

While I have found a way around the problem, it would be nice to know what's going on.

Rob 

[xcrow81]

man, for what i read it look like the ERARNGE routine plus the rutine that chech for complete page is taking to long . ERARNGE  could take up to 5.5 ms and you can not feed the watchdog inside any flash routine (maybe if you are extremely carefully you could) because you shouldn read o write flash while you are writing or erasing it.  a simple solution is to trust your flash routines and  desactivate the dog when you write de memory.
it didnt fail everytime because  ERARNGE only run when de page you are using became full.