Page 3 of 4

Re: Greetings

PostPosted: Mon Jun 23, 2014 4:50 pm
by K9ACT
s
Ian.M wrote:XC8 v1.32 puts the program right at the end of the memory (even short programs) with a GOTO at location 0 to jump to it. The fix is only needed if you are having problems with MPLAB 8 SIM and getting that specific error message. While it is harmless, it should not be used when programming a real chip, as PIC16 devices have no problems if you let execution wrap around, and it does waste a word of program memory.


Bottom line seems to be that I can not use the Pickit 2 program to flash programs built on XC8. The work around is to use the built in programmer functions but they seem stone age by comparison. Another score for MicroC.

Question: What is the double underscore for in front of delay in Ric's program? It won't run in hardware without them and again MicroC couldn't care less.

One more question: What is the .as file that keeps getting in the way of what I am trying to look at? seems to have something to do with Java but is it anything I need to be concerned with.

js

Re: Greetings

PostPosted: Mon Jun 23, 2014 5:00 pm
by K9ACT
Someone named "Code Critter" posted an interesting response but I can not post to that forum anymore. It just ignores all answer options.

If you are here, please repost or send me email jack@schmidling.com

If not, would someone please advise him via that other forum.

Thanks,

js

Re: Greetings

PostPosted: Mon Jun 23, 2014 11:23 pm
by ric
K9ACT wrote:...
Question: What is the double underscore for in front of delay in Ric's program? It won't run in hardware without them and again MicroC couldn't care less.

That is simply how they have named the delay macro. I assume it is for historical reasons, Hitech C used the same name.
It is documented on page 330 of the XC8 User's Guide.

Re: Greetings

PostPosted: Tue Jun 24, 2014 1:52 am
by jtemples
In C, symbols with leading underscores are reserved for the implementation. This means that a compiler vendor can introduce a symbol like __delay_ms into a header file without the risk of a collision with a user-defined symbol of the same name.

As for why all of the SFR symbol names don't start with an underscore, I don't know...

Re: Greetings

PostPosted: Tue Jun 24, 2014 8:01 am
by vloki
K9ACT wrote:Bottom line seems to be that I can not use the Pickit 2 program to flash programs built on XC8. The work around is to use the built in programmer functions but they seem stone age by comparison. Another score for MicroC.

This makes no sense since in my opinion here is no reciprocal effect between compiler and programmer.

Re: Greetings

PostPosted: Tue Jun 24, 2014 4:26 pm
by Ian.M
Unless he's using obsolete PICkit 2 software that may be crashing on an XC8 v1.32 HEX file.

@K9ACT: We need to know exactly what version PICkit 2 standalone software and device file you were trying to use and exactly what went wrong when you tried to use it to load a HEX file and program your chip.

Re: Greetings

PostPosted: Fri Jun 27, 2014 6:14 am
by K9ACT
Ian.M wrote:Unless he's using obsolete PICkit 2 software that may be crashing on an XC8 v1.32 HEX file.

@K9ACT: We need to know exactly what version PICkit 2 standalone software and device file you were trying to use and exactly what went wrong when you tried to use it to load a HEX file and program your chip.


Pickit2 v2.61.00 and device file 1.61.00

When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.

Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.

js

Re: Greetings

PostPosted: Fri Jun 27, 2014 8:18 am
by vloki
K9ACT wrote:When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.
Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.
js

This sounds *a bit* unlikely ;)
Did you try to view your hex file in an editor ?
May you post one ?

Re: Greetings

PostPosted: Sat Jun 28, 2014 4:57 am
by K9ACT
vloki wrote:
K9ACT wrote:When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.
Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.
js

This sounds *a bit* unlikely ;)
Did you try to view your hex file in an editor ?
May you post one ?


I have attached screen shots of the first and last page of the Pickit 2 hex display and
the following is a Word view of the hex created by the code from ric.

The program loads and runs in hardware.

js



:040000000000FD2FD0
:100FB0008316031386018312031386010330F200A4
:100FC0008A30F1005630F000F00BE42FF10BE42FE3
:100FD000F20BE42FEB2FAB308312031386000330A8
:100FE000F2008A30F1005630F000F00BF52FF10BD3
:0E0FF000F52FF20BF52FFC2FDB2F8301D82FEE
:02400E0038FF79
:00000001FF

Re: Greetings

PostPosted: Sat Jun 28, 2014 6:08 pm
by Ian.M
Nothing surprising here. The six lines of the HEX file that are in the FLASH program memory area match the two PICkit 2 memory screenshots.

The first line of the HEX file is a NOP followed by GOTO 0x7FD
The subsequent five lines of the hex file are a block of code located between 0x7D8 and 0x7FE
Then there is a line giving the CONFIG word and the final line is an end of file record, both of which don't appear in the program memory.

This is exactly what I would expect if the compiler is using a top down FLASH allocation strategy, and you have the NOP at address 0 for hardware debugger support and you are using my ROM range patch to prevent bogus address wraparound errors in the simulator.

You'd better read up on IntelHEX!