Program will not run when it is over a certain size.

[Zane]

Hi I am using a PIC18F4685 for a project, it has 96K of program memory. The program is used to interface with a 4D graphical LCD. The size of the project is quite large and uses just over 80% of the available program memory of the PIC.

During the development of the program everything was working fine until two large blocks of code were imported into the program. If they are removed the program works again however if I leave them in and delete other sections of code equal to a similar size the program also works. The size of one cut down program that worked used approx 55% of the program memory.

At the start of the program the first two steps have a component macro initializing the gLCD. The next step a component macro writes a message to the display saying the display has been initialized. When a cut down version of the program is used the display shows the message ok. If the full sized program is used the display reverts to the 4D labs splash screen. There is also an interrupt routine that drives a cpu active led. With the full size program this no longer works.
The compiling all seems to work ok with all return codes of “0” and the when the program has been sent it verifies ok.

The configuration of the chip all seems ok with the extended cpu off as I have had issues with that in the past and all the table read protections all disabled.

I have also tried this using a different chip PIC18F2685 and had the same results.

Any help with this would be most appreciated.

Thanks

Zane

[Benj]

Hi Zane,

Any chance you could send me your programs, one that works ok and one that doesn't work and I will look into it for you. If the programs are commercially sensitive then you can send them to me using a PM rather then attaching to the public forums.

[Zane]

Hi Benj,

I have sent copies of the software to your sales@matrixmultimedia.com address as the files sizes are too large to be accepted by a PM. Thanks for your help

Zane

[Zane]

Hi Benj,

I have tried using the ICD function. I have found that if I use a smaller sized program that the program runs and the ICD functions as required. With the larger sized program after the chip is programmed and you start to run the program a message is displayed that says the ICD function cannot communicate with the target device.
You mentioned in a PM that my program and its configuration all looked ok and that this could be an issue with the compiler causing the program to run out of page memory. What steps could I take next to determine if this is the case. If anyone else has any ideas, your help would be most appreciated.

Thanks

[Zane]

From Kenrix2

Cannot post in FCV5 forums.....

You can try HI-TECH C version 9.80 compiler. You want the one for pic18.

Instructions to set it up with flowcode are here (follow directions carefully as it has separate instructions for V4, V5, pic 16, pic 18):
viewtopic.php?f=26&t=6812
Note the empty field in the photo in Linker/Assembler....Parameters.
To revert back to boostc in V5 the "build" menu then "compiler options" has a default in the top right. I think you can also name and save Hi-Tech C settings.

Here is a link to High-Tech C, there is a free version (Lite). Sign up is required .
http://www.microchip.com/stellent/idcpl ... e=en542861

You could also consider using external eeprom but your data speed will be reduced by at least 1/8 because they are serial. If you need quick large picture changes I am not sure how well it would work. If you are using 100's of small pictures it might be just fine.

[Zane]

Hi Benj,

I have tried to compile my program using the Hitech compiler to eliminate the boostc compiler. I end up with a whole heap of error messages mainly "pointer to unsigned char" and "illegal conversion between pointer types". I have searched the forums for any signs of these errors without any luck. Do you or anyone else have any ideas for a fix fo this? I have a attached a copy of the compiler results.

Thanks.

[Zane]

From Kenrix2 via PM

The difference between boostc and HITEHC C is lower case(boostc) and UPPER CASE (HITECH C), so to make Flowcode compatible with HITECH C they added a definitions.h file which changes lower case to UPPER CASE. They added register names but, not individual bit names. So when you see undefined identifier "TXREQ" you can add this to "supplementary code" as follows:
#ifndef txreq
#define txreq TXREQ
#endif

Also you have undefined identifier "RXFUL", so try this:
#ifndef rxful
#define rxful RXFUL
#endif

Please keep in mind I do not have V5 nor do I have HITECH C PIC18, so I can not test any of this. It also may not be that simple since txreq is bit 3 of register BnCON where n is 0 ≤ n ≤ 5.

As to the warnings, I have not a clue.

[Zane]

Thanks for pointing this out. I had a look through the forums and found a post with issues regarding the lower case and an updated definitions.h file was created to get around this. I looked at the date of this updated file and the file in my pc was the same. As for the errors i have i will take your advice. I am a bit short on time at the moment but will let you how i get on. Thanks.

[Zane]

Hi Benj,

I have posted a question on the Source boost forums in regards to the program not running on the chip when over a certain size. The reply i got was " When the code goes over the 64k byte mark the hex file contains Extended Linear Address Records.Does your programmer support these records or are they being ignored.Since you can select the correct device on the programmer one would think so. Worth checking though."
Can you confirm if this is the case or not.

Thanks

Zane

[Benj]

Hi Zane,

Aha that's interesting. What hardware are you using to program the device?

[Zane]

Hi Benj,

I bought a new programmer off Matrix about 6 weeks ago, a E-blocks USB PICmicro multiprogrammer board. My older version board without the ICD function gave the same results.

I have had another PM from Kenrix2 which he has forwarded to you too. The post is below.

I think the people at sourceboost are correct. It is a problem with the programmer using extended addressing.
Please try this to test their theory. Please keep in mind I do not have Flowcode V5, I have V4. So that is the reason for this PM since I can not reply to V5 posts and some of my instructions may not be exactly correct but I am sure you can figure it out.

In "Compiler Options" find the field " Linker/Assembler: Parameters:".
add this to the begining of that field -hexela with no space before it and one space after it. So it should look something like
-hexela -ld "C:\Program Files\Matrix Multimedia\Flowcode V4\BoostC\lib" libc.pic16.lib flowcode.pic16.lib rand.pic16.lib float.pic16.lib "%f.obj" -t PIC%p -d "%d" -p "%f"
V5 will be at a different location on the hard drive.

Sadly, I suspect this is also going to bring up another issue, your program will grow in size and may not fit. I have CC'ed this to benj in case he has any suggestions.

[Zane]

I have tried to download the program with adding "-hexela" at the start of the Linker/Assembler Parameters.
the chip programs but at the end the following is displayed-

Writing configuration memory
Programming failed: <8><10><12>
That took 444.852 seconds
Return code = 0
FINISHED

I plugged in the 4D display and the screen clears and then it starts to fill the screen from top to bottom in purple then the screen looks like it is resetting and the process is repeated. The first time i tried this the screen fill colour was grey. In my code there is no function that does the above nut now looks like some portion of code is running.

[Zane]

Hi Benj,

I'm just wondering, have you had any ideas of how i can get around this problem, is there any thing i can do to assist?. I have run out of any further ideas to find a solution to this, it would be really great to get this working.

Thanks

Zane

[Zane]

Hi Benj,

I’m just wondering what is happening with this problem being unable to run my program on a PIC18F4685 when the program is over 64k. I have made repeated requests for help but have had virtually no feedback. Basically I just need to know where I stand. Are you looking into this problem? Do you think it is an issue with the programmer and is the EB006 capable of programming any chip with a program memory of over 64k? Do you think the problem may still reside in the compiler? Most importantly can it be resolved or should I find an alternative solution for programming this type of chip?

You say that you were unable to test this problem out as you did not have a PIC18F4685. Would it help if I bought another and sent it to you at Matrix?

I am very keen to find some kind of resolution to this. Thanks for your help and I look forward to your reply.


Thanks

Zane

[Benj]

Hi Zane,

RIght I'm sorry about the delay in getting back to you. I was not aware of this over 64KB limitation in our software but as you say there is a problem. No we haven't currently been able to replicate the issue here, mainly due to lack of time.

We cannot currently do anything to fix the PPP software however we are working on our next generation programming tool mLoader which once complete will work work with the EB006 and should solve the issue.

For now I would suggest you do this as a workaround. Get hold of a PICkit 3 programmer and use the ICSP socket on the EB006 to connect the programmer to the E-blocks board. This way we can rule out the programmer/software as an issue as the PICkit should be able to cope correctly with the addresses over the 64KB address.

I could try this workaround on a chip for you if it would help and save you purchasing the additional PICkit.

[Zane]

Hi Benj,

Thanks for your reply. With the mLoader software, when do you think that will be ready for release? As for the pickit, i don't own one but was looking at getting one. Would i be correct in saying that you would take the generated c code and place that into mplab and program from there using the eb006 to hold the chip being programmed?

Thanks

Zane

[kersing]

Hi Zane,

You would use Flowcode to generate a hex file, import the hex file into mplab and use the PICkit to program the hex file. I use this work flow regularly for custom hardware. Another way is to call the command line tool for PICkit directly from Flowcode (in stead op PPP) to program the chip.

Best regards,

Jac

[Zane]

Hi Jac,

Thanks for this info, i will go ahead and get a pickit and give it a go. Just out of curiosity could you cut and paste the c code into mplab and then use the c18 compiler to generate the hex code or would you need to add other code so it worked?

Thanks

Zane

[kersing]

In general cut-and-paste will not work. It can be done, you need to purchase the same compiler used for Flowcode and create a mplab project for each Flowcode project. Creating the mplab project is generally a lot of work due to the dependencies used by Flowcode C files. C18 will not work with the code generated by Flowcode, it requires adaptations to the generated C source.

[Zane]

Thanks for that info, just wondering if it was possible without a whole lot of extra work. I still give the pickit a try. Thanks.

[Zane]

Just an update, i have got hold of a pickit3 programmer and downloaded the program (over 64k) and the program runs ok.