Greetings

This forum handles questions and discussions concerning Microchip’s 8-bit compilers, assemblers, linkers and related tools.

Re: Greetings

Postby K9ACT » Sun Jun 22, 2014 2:55 pm

That was easy.

It builds but will not run in simulator.

Hex looks normal in Word but Pickit2 will not load it, just bunch of 3fffs.

Ja
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby K9ACT » Sun Jun 22, 2014 5:40 pm

K9ACT wrote:That was easy.

It builds but will not run in simulator.

Hex looks normal in Word but Pickit2 will not load it, just bunch of 3fffs.

Ja


Here is an update.

I can get it to program in PK2 using the tools in XC8 but still no joy using the either PK1 or 2 stand alone programs.

Still no joy with sim. Is this supposed to work with the C program?

js
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby Ian.M » Sun Jun 22, 2014 6:40 pm

The simulator does work with C programs, but the simulation speed is far slower than the real chip. The 500ms delay is 500000 instruction cycles and if you don't want to take a teabreak while it executes, you may need to reduce _XTAL_FREQ by a factor of 100 and re-build. Don't forget to undo the changes before building to program a real chip.

XC8 v1.32's program memory allocation strategy seems to be top down. The HEX file starts with a jump to the C startup code but then there's a big gap in the memory map before it gets to the main code. That probably explains all the 0x3FFF locations you are seeing.
Last edited by Ian.M on Mon Jun 23, 2014 1:04 am, edited 1 time in total.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Greetings

Postby jtemples » Sun Jun 22, 2014 10:10 pm

Ian.M wrote:The simulator does work with C programs, but the simulation speed is far slower than the real chip.

I just tested this with a variant of ric's program running the MPLAB X simulator. I added six __delay_ms(10000) calls for a one-minute delay, which took 22 seconds of real time with XTAL_FREQ still at 4 MHz. So the X simulator can run the equivalent of about 11 PIC MHz in real time. I didn't try with MPLAB 8, but I can't imagine it's slower than X's Java implementation.
jtemples
Verified identity
 
Posts: 195
Joined: Sun May 25, 2014 2:23 am
Location: The 805
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby Ian.M » Sun Jun 22, 2014 10:15 pm

I should have said "can be much slower". It does depend on your PC's CPU and also on various simulator settings.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Greetings

Postby jtemples » Sun Jun 22, 2014 10:40 pm

K9ACT wrote:Still no joy with sim.

What does "no joy" mean? What did you try? What did you see? What did you expect to see?

Is this supposed to work with the C program?

The simulator has no knowledge of what language your code is written in, just like the PIC doesn't. They just execute machine instructions.
jtemples
Verified identity
 
Posts: 195
Joined: Sun May 25, 2014 2:23 am
Location: The 805
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby Ian.M » Mon Jun 23, 2014 12:57 am

There is a bug in the MPLAB 8 simulator: When the address counter is incremented past the last address of the program memory, you get the error message:

CORE-W0014: Halted due to PC incrementing over the Maximum PC address and wrapping back to Zero

which depending on your simulator settings can halt execution. Unfortunately when executing a CALL, GOTO, or any sort of RETURN, the address wrap is checked before the program counter is updated with the target (or return) address so a GOTO or RETURN right at the end of the program memory can falsely throw the above error.

The simple fix is: Don't use the last program memory location, which you can achieve by adding a restriction to the ROM ranges box of the Global tab of the Project Build Options. For this chip:

-7FF-7FF

will work nicely, preventing the last address (0x7FF) from being used. Old versions of the compiler and assembler programs rarely trigger this MPLAB SIM bug because memory is usually allocated bottom-up so the last location is less likely to be used.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Greetings

Postby K9ACT » Mon Jun 23, 2014 5:55 am

Ian.M wrote:The simulator does work with C programs, but the simulation speed is far slower than the real chip.



I forgot about the delays and that is where the sim did just sit and do nothing. I commented // them out and it works just fine. Seems like in asm, the cursor would blink at the delay and wake me up to comment it out.

I think I forgot because when I run the same program in MicroC, the sim just ignores the delays. Score one for MicroC.

>XC8 v1.32's program memory allocation strategy seems to be top down. The HEX file starts with a jump to the C startup code but then there's a big gap in the memory map before it gets to the main code. That pro
bably explains all the 0x3FFF locations you are seeing.

Not sure I understand all that but does it mean that I can't look at the hex file or use the Pickit2 program?
The only way I can see the hex is using Word which is not very helpful. It is sometimes useful to read the hex from a chip and load it into another.

To make clear what I am seeing is ALL locations are 3fff except the first one which is 2ffe.

............ actually that is not true, I just looked again and the program seems to start at 7f7 but then runs out of memory or whatever after the next line.

The Pick1 program just crashes and shuts down when I try to load the hex.

Jack
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby K9ACT » Mon Jun 23, 2014 6:14 am

Ian.M wrote:There is a bug in the MPLAB 8 simulator: When the address counter is incremented past the last address of the program memory, you get the error message:


The simple fix is: Don't use the last program memory location, which you can achieve by adding a restriction to the ROM ranges box of the Global tab of the Project Build Options. For this chip:

-7FF-7FF


I assume this does not apply to the program we are concerned with as it not long enough to get to the end of memory.

I put in the fix anyway and it makes no difference as far as the Pickt 2 program looks.

js
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby Ian.M » Mon Jun 23, 2014 7:22 am

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.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

PreviousNext

Return to MPLAB XC8

Who is online

Users browsing this forum: No registered users and 6 guests

cron