SpokaneNexus
...Thank you so much for initiating that internally! I suspect that carries a lot more weight than an external request. Given that you're doing that, does it still make sense for me to follow your advice and "suggest this feature to be added to MPLAB X IDE"? Or is that redundant now that you're doing it internally?...

Hello SpokaneNexus,
 
It is my pleasure -- you are very welcome. I wrote the enhancement request and logged it into our system.
 
I feel that customers definitely have more weight and it definitely would not hurt if you contacted Microchip to indicate how useful this feature would be to you. I don't have any (managerial) control as to when (or if) the feature will be added to MPLAB X IDE so that is why I feel the customers' voice is very important to be heard from.
 
It is a 'high-value target' debug feature that adds a lot of value in my opinion. Since the Debug Executive is shared among all tools that support target debugging (old and new), all tools can potentially benefit by this feature. 
 
I thank you as well for voicing your frustration in these Forums -- I'm glad I saw this thread!
 
Best regards,
 
Ken
 
P.S. SpokaneNexus, out of curiosity, may I ask you a question?:
 
Besides Debug Mode Reads of flash memory and Data EEPROM, would you find any beneficial value having Debug Mode Read capability for these additionally memory areas?:
 
1) User IDs
2) Configurations Words
3) Device Information Area (DIA) memory (if exists on MCU)
4) Device Configuration Information (DCI) memory (if exists on MCU)
 
 
 Edit: DIA/DCI acronym corrections.

SpokaneNexus
...Speaking only for me personally, I would find value in 2-4. I haven't run into a need for #1 (yet!). Recognizing that the ICD has limited resources and thus we have to prioritize, I'd choose 1) EEPROM, 2) DIA, 3) DCI, 4) Configuration words, and 5) User ID's, in descending order of preference...

Thanks very much SpokaneNexus for your time and for providing your input -- it is appreciated!

Hello Spokane
 
MPLAB-IDE and MPLAB-X does not automatically update the EEPROM window to the best of my knowledge.
 
I always had to do a read in order to update the EEPROM window, after hitting a break point or pausing the debbugger.
 
 
Regards,
Frikkie.
 
 

Update: I have received notification on my support ticket that this feature has been passed to their Engineers. They promise to keep me updated, and I'll post anything significant here as things progress.