Not enough RAM - PIC16F1705

[aCkO]

It looks like the MCU definition file (MLK) is completely messed up and it seems that more devices from PIC16 Enhanced family are affected. Unimplemented memory locations are incorrectly specified in BADRAM section as you can see in the screenshots below.

P16F1705_1.PNG (111.41 KiB) Viewed 8876 times

P16F1705_2.PNG (6.54 KiB) Viewed 8876 times

Funny thing is that all "isolated" registers are affected, but also other ranges that shouldn't be there are present. The main reason why you couldn't allocate that much RAM for your array (and why this issue became apparent) is because linear data memory was "broken" into smaller pieces by the inclusion of locations 0x02A0 and 0x0420 in BADRAM section.

Attached is MLK file that should fix this issue. Just extract it to <INSTALL_DIR>\Defs overwriting the existing one (backing up the old one is a good idea in case I missed something).

Regards

[Toley]

Thank you very much aCkO, as usual your solution seems to work very well.

I have another question, should I use the ldm type qualifier to declare such a big array to make sure the addresses are linear?

Hoping mE will take action quickly to correct those incorrect MCU definitions.

[aCkO]

I have another question, should I use the ldm type qualifier to declare such a big array to make sure the addresses are linear?

You can use it, but it is not necessary. By definition, arrays are blocks of continuous memory. mC handles that internally.

Regards

[rajkovic]

Thank you very much aCkO, as usual your solution seems to work very well.

I have another question, should I use the ldm type qualifier to declare such a big array to make sure the addresses are linear?

Hoping mE will take action quickly to correct those incorrect MCU definitions.

We will check mlk, but I do not think there are errors, unimplemented parts are declared as badram in mlk.

You are right

Code: Select all

 ldm 

should be used when declaring arrays that are bigger
than largest chunk of RAM bank can handle.
So code should look like

Code: Select all

ldm unsigned short Pixels[400];

void main()
{
    Pixels[0] = 0x00;        // Simple Initialization
}

, and will work with original MLK.

[Toley]

and will work with original MLK.

Hi rajkovic, did you try it? It gives the same error with the original .mlk.

[janni]

We will check mlk, but I do not think there are errors, unimplemented parts are declared as badram in mlk.

There certainly are errors in enhanced family mlk files. I always check definition files for any processor I use (of any family) because most have to be corrected (apparently my standards are too high and cannot tolerate situation when something works just most of the time), but the enhanced family files form an example of sloppiness .

You are right

Code: Select all

 ldm 

should be used when declaring arrays that are bigger
than largest chunk of RAM bank can handle.

Actually, compiler always uses linear data memory when accessing arrays, so the ldm specifier does nothing here.

So code should look like

Code: Select all

ldm unsigned short Pixels[400];

void main()
{
    Pixels[0] = 0x00;        // Simple Initialization
}

, and will work with original MLK.

It works also without the ldm specifier, but it won't work with array size greater than 400 and that's the point. Error in mlk file, pointed out by aCko, causes compiler to balk when the wrongly eliminated address 0x2A0 is encountered as it constitutes a hole in linear data memory.

ADDED: Errors in mlk file that wrongly declare existing SFRs as "bad ram" do not produce compiler errors in c definition files only because compiler dismisses "bad ram" specifications for declarations with the sfr specifier - which by itself is an error.

[Toley]

Curiously, trying to compile with other members of the familly don't give this error. PIC16F1709 which is identical in term of memory, don't give this error. Even his little brother PIC16F1704 who have half the RAM compile correctly. It looks like only the 1705 mlk was corrupted and I fall on it.

[janni]

Yes, this particular error concerns newer files/processors. Still, there are tens of these (PIC16F1709 among them - you must have missed the spot as address 0x02A0 is listed as "bad ram" among others errorneously classified as such).

[filip]

Hi,

I will check this issue and inform our developers.

Regards,
Filip.

[janni]

Thank you. It would be nice if during the 'cleaning' of definition files the problem with configuration words was also corrected (in processors where unimplemented configuration bits are read as 1 definition files should not fill these bits with zeros as then configuration words written to processor differ from read ones).

[fred85]

Hi,

I will check this issue and inform our developers.

Regards,
Filip.

What did your developer(s) say? Are they planning on fixing this in the near future?

[filip]

Hi,

I will try to push them to fix this ASAP.

Regards,
Filip.

[aCkO]

This might help:

MlkChecker.png (23.99 KiB) Viewed 8418 times

I made a small app that compares MLK files with XC8 definition files and lists/fixes memory blocks incorrectly marked as BADRAM.

Here's the output:

Code: Select all

P16F1614

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1615

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1618

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1619

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1705

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1709

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1713

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1716

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1717

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1718

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1719

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16F1764

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1765

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1768

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1769

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16F1829LIN

BAD=9F-A0, DATA=A0-EF
BAD=11F-120, DATA=120-16F
BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1705

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1709

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1713

BAD=29F-2A0, DATA=2A0-2EF
------------------------------------
P16LF1716

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1717

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1718

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------
P16LF1719

BAD=29F-2A0, DATA=2A0-2EF
BAD=41F-420, DATA=420-46F
------------------------------------

As you can see, total of 23 devices are affected with "off by 1" error.

EDIT: Replaced with version that fills empty MAPPEDMEMORY sections.

Regards

[fred85]

This might help:

MlkChecker.png

I made a small app that compares MLK files with XC8 definition files and lists/fixes memory blocks incorrectly marked as BADRAM.

As you can see, total of 23 devices are affected with "off by 1" error.

Regards

Thanks aCkO.

[janni]

As you can see, total of 23 devices are affected with "off by 1" error.

Good work but there are more such faulty files that your comparison missed, for example for 12F1571, 12F1572 or 16LF1612, 16LF1613, and there's also another error to be considered - empty 'mapped memory' section.