Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

MPLAB (7.41) Eeprom simulation bug

Status
Not open for further replies.

Exo

Active Member
Hi,

I found a bug in MPLAB 7.41's simulator regarding the internal data eeprom
when you are performing interrupt based eeprom writing. (start write - do something else - on interrupt start write of next byte - do something else - ...)

On a real pic, when you start an eeprom write to adress X, then already change the address for the next write (for example , INCF EEADR, to have it ready for the next byte to be written) you will find that when the write completes and the eeprom interrupt flag is set (PIR2<EEIF>) the eeprom address register (EEADR) is back to value X.

However , in the MPLAB sim this isn't the case, When the write completes EEADR is unaffected.

I'm just sharing this because i spent 3 hours finding an 'error' in my code wich didn't work for real but did fine in the MPLAB sim.

EDIT: PIC16F in this case, i don't know about PIC18F's behaviour
 
Quite hard to debug a complex program that takes 7K of a 16F877's ROM without a simulator ... :/

I try my best but i can't look inside the pic ;)
 
Exo said:
Quite hard to debug a complex program that takes 7K of a 16F877's ROM without a simulator ... :/

I try my best but i can't look inside the pic ;)
You don't use an ICE or ICD? Nothing like seeing inside the real thing. I have an old Tech-Tools ICE for the 16F877. Saved hours if not days of hair pulling. Now I'm porting to my code to work with MPLAB and the cheap & cheerful ICD2 clone on my site. It's no ICE but it'll work in a pinch.
 
Last edited:
I got an ICE.

Still , Stepping trough your code in the mplab sim to remove the bulk of the "doh!" bugs without having to whip out the hardware is quite nice :)
 
I've run into a number of inconsistancies between the simulator and real chips whe it comes to the eeprom in mplab 6.x. I don' think microchip really cares since I reported them and they haven't made any changes. I sure wasted way too much time debugging the simulator and not my code.

bottom line for me is that I find it much faster to read my code carefully for the Doh! errors and then debug on the real hardware. It's no hardship to "whip it out" because you'll need to run on it soon enough. relying on stepping through code for sanity checking code is the slow way to program.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top