Jump to content

Recommended Posts

DTPIC    0

In SourceBoostC ver 730, I have noticed that some 18Fxx'K'yy CPUs are returning the wrong program memory size in the IDE (it is often 2x correct value). Examples: 66K22, 67K22.

If I look in the .tdf files for these CPUs, the same "incorrect" values are present as the program memory ranges. The values are 2 x the size shown in the CPU data sheet.

This leads to the IDE \ compiler stats being incorrect after a compile (eg, "ROM available:",  "used:" and  "free:" figures)

 

 I have checked a "correct" CPU tdf (eg, 44K22) and the size agrees with the data sheet, and is displayed correctly in the IDE...

 

Am i missing something about the "factor of 2" on these CPUs? Or is this just a plain and simple error?

 

(It has turned up on other CPUs too - I will list as I come across them again...)

 

This may be "old news" now that Chameleon is out, but other users may still be working on 730 and it may be that the error has carried over into the new compiler support files....

Share this post


Link to post
Share on other sites
Reynard    0

Check that the data sheets are not specifying number of instructions as one instruction is two bytes.

Cheers

Reynard

 

Share this post


Link to post
Share on other sites
DTPIC    0

Thanks Reynard, but that was my first thought too!  (I have  been caught before with that one...).

If I play with the compiler, I can see some CPUs with values which agree with the data sheets, and others which do not - even though the data sheets are all specifying "Flash (bytes)", not "instructions.

Also, some TDF files agree with the associated data sheets (eg 44K22), while the TDF for 66K22 does not agree - so there is some inconsistency worth checking!

I have had a situation where the compiler says "all OK, only used just over 50% program memory" while MPLAB wont load the hex file into the CPU properly  because its too big....

As an example, my current project uses 66K22: the compiler is saying "ROM available 131072 bytes, ROM used 34774 bytes (26.1%)". But if I look at the program area of the hex file in MPLAB, it has a limit of 0xFFFF (65536 bytes) and has code up to 0x87D6 (which is the 34774 bytes specified by the compiler). Clearly not 26% utilisation..... more like  53%.... compiler is wrong....

Share this post


Link to post
Share on other sites
Reynard    0

You are correct in your findings.  Some of the tdf files are specifying the incorrect program address range.

This is a subject that came up a few years ago but who wants to go through all the tdf files to find the errors.  Hopefully they will be corrected as they are reported.

My main work horses are the 26k22 and 46k22 which appear correctly specified.

Cheers

Reynard

 

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×