Beta 7.3.0 - EEPROM
Beta 7.3.0 - EEPROM
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.
Re: Beta 7.3.0 - EEPROM
Hi,
You are right about this, we will solve this in the official release.
Regards,
Filip.
You are right about this, we will solve this in the official release.
Regards,
Filip.
Re: Beta 7.3.0 - EEPROM
When we will see this official release? Next year?filip wrote:Hi,
You are right about this, we will solve this in the official release.
Regards,
Filip.
Serge T.
Learning is an endeless process but it must start somewhere!
Learning is an endeless process but it must start somewhere!
Re: Beta 7.3.0 - EEPROM
Hi,
Currently, I don't have such information, but I will inform you as soon as I get it.
Regards,
Filip.
Currently, I don't have such information, but I will inform you as soon as I get it.
Regards,
Filip.
-
- Posts: 1549
- Joined: 24 Jun 2007 19:27
- Location: 01800 St Maurice de Gourdans France
- Contact:
Re: Beta 7.3.0 - EEPROM
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
why using a compiler ?
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 we must change manually some adress to get a working program,If you want it to go to EEPROM (which is at 0x310000), try replacing this line from the HEX file:
:020000040121D8
with this:
:020000040031C9
why using a compiler ?
Re: Beta 7.3.0 - EEPROM
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 wrote: if we must change manually some adress to get a working program,
why using a compiler ?
-
- Posts: 1549
- Joined: 24 Jun 2007 19:27
- Location: 01800 St Maurice de Gourdans France
- Contact:
Re: Beta 7.3.0 - EEPROM
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)
recompile and reload
==== APRES ===========
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)
after doing the manual change in Eeprom fie (*.ihex) start adresseLoading 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..
Code: Select all
OLD adresse :020000040121D8 1210 H
NEW adresse :020000040031C9 3100 H
==== 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
- mikroElektronika team
- Posts: 1135
- Joined: 18 Dec 2018 10:30
Re: Beta 7.3.0 - EEPROM
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,
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,
Stefan Filipović
Re: Beta 7.3.0 - EEPROM
But three new compiler versions were released .paulfjujo wrote:With version 7.6.0
EEPROM editor gives sam bug for 18F27K42 .. since January 2019 !
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 .
Re: Beta 7.3.0 - EEPROM
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.
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.