Beta 7.3.0 - EEPROM

[janni]

It's funny how old mistakes tend to stick or even resurface . EEPROM addresses in K42 and K83 definition files are still wrong, which means that EEPROM Editor is ineffective in presetting EEPROM contents (same thing goes for some other families, like K40, 16F18xxx or 19xxx). EEPROM_Write function, contrary to Help, waits till write is finished instead of waiting for end of previous write (if any). This function also enables all interrupts, whether they were active before or not.

[filip]

Hi,

You are right about this, we will solve this in the official release.

Regards,
Filip.

[Toley]

Hi,

You are right about this, we will solve this in the official release.

Regards,
Filip.

When we will see this official release? Next year?

[filip]

Hi,

Currently, I don't have such information, but I will inform you as soon as I get it.

Regards,
Filip.

[paulfjujo]

hello,

Same problem with use of PIC18F27K42 Eeeprom

i get an answer from Microchip forum wich solved my problem
https://www.microchip.com/forums/m1087628.aspx#1087642

If you want it to go to EEPROM (which is at 0x310000), try replacing this line from the HEX file:
:020000040121D8
with this:
:020000040031C9

if we must change manually some adress to get a working program,
why using a compiler ?

[janni]

if we must change manually some adress to get a working program,
why using a compiler ?

True. Still, this one is a definition file error, so you can correct the file once without the need to modify hex files. See here, for example.

[paulfjujo]

hello,

With version 7.6.0
EEPROM editor gives sam bug for 18F27K42 .. since January 2019 !
i must manualy change starting adresse of eeprom into the file *.iHex
When this will be solved ?

When using MPLAB IPE + Pickit4

without correction in eeprom file, i get this WARNING
unfortunatly ,i didn't use Eeprom data in my application , so i was locking for another problem !!!
wich does not exist (from my part)

Loading code from C:\_MikroC\_MesProjets_MikroC\_Horloge_Anneau_60leds_18F27K42\Horloge_PIC18F27K42_Anneau_60leds_4_Reverse_Matrices_Max7219_191027.hex...
Warning: C:\_MikroC\_MesProjets_MikroC\_Horloge_Anneau_60leds_18F27K42\Horloge_PIC18F27K42_Anneau_60leds_4_Reverse_Matrices_Max7219_191027.hex contains code that is located at addresses that do not exist on the PIC18F27K42.
Code incompletely loaded.
2019-10-28 15:56:42 +0100 - Hex file(s) loaded successfully.
2019-10-28 15:56:45 +0100 - Programming..

after doing the manual change in Eeprom fie (*.ihex) start adresse

Code: Select all

OLD adresse  :020000040121D8     1210 H
NEW adresse  :020000040031C9     3100 H

recompile and reload

==== APRES ===========

Loading code from C:\_MikroC\_MesProjets_MikroC\_Horloge_Anneau_60leds_18F27K42\Horloge_PIC18F27K42_Anneau_60leds_4_Reverse_Matrices_Max7219_191027.hex...
2019-10-28 16:32:16 +0100 - Hex file(s) loaded successfully.
2019-10-28 16:33:46 +0100 - Programming...

[stefan.filipovic]

Hi Paul,

I apologize for the inconvenience caused by this, I will forward it to our developers.

Have you tried this workaround?
viewtopic.php?f=88&t=69725

Kind regards,

[janni]

With version 7.6.0
EEPROM editor gives sam bug for 18F27K42 .. since January 2019 !

But three new compiler versions were released .

More seriously, though definition files have been updated, the update concerns mostly CODEGRIP ICD, which so far has no bearing on PIC compilers. Wrong EEPROM addresses have not been corrected.
But there's more: EEPROM_Write still won't work for bigger P18 processors, like PIC18F67xx or IC18F87xx. Contrary to description in Help, EEPROM_Write waits for end of write (and, for most of P18 processors, for end of previous write as well). For some processor series, like K40, K42, P16F19xxx, etc. interrupts are blocked for entire write time (several milliseconds ) which may easily brake any serial communication based on interrupts. And for P16F183xx and P16F188xx processors the EEPROM functions are claimed (and accordingly written) to be able to read and write two bytes at a time .

All the above concerns only one peripheral but I'm afraid it well illustrates where mE's compilers are going .

[ecuserwis]

Unfortunately this fraudulent approach applies to patches in all compilers.
I have bought 4 keys, a total of 1000-1200 USD spent , and in each compiler is reported what is not working and has never been corrected until today
Probably the most strange is the FT900 compiler which is for processors that are not produced because a new MCU revision was released very quickly - to this day silence from Mikroe , so I bought a processor compiler that is not on the market !!!
The only thing I got thanks to the Mikroe compiler is that I started working with professional software - IAR, Keil, MPLAB, CCS for PIC, and I'm learning GCC with ECLIPS.
It is possible that this is their mission ... to force the client to learn another tool.
Also, it is the usual insolence to release a new NECTO environment for money without improving previous versions of compilers, of course I believe that everyone can see it strange behavior.