I flashed FF onto a PIC18F4520 today using AS from mplabX 6. Forth works on it but the warm word doesn't seem to do anything. Could you guide me on what might be wrong
Several months ago I had flashed the same chip with an older version of FF using mplab 8 and that didn't have this issue.
Hi,
There is a risk that XC8(PIC-AS) compiles faulty code because it does not warn about out of range relative jumps. I complained to microchip about this and it seems the latest 2.40 version has a fix for that. But I have not tried it yet.
Also I have never verified the PIC18Fx520 with PIC-AS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chaning the stringlength to 37 from 38 resolved the issue!
Ah, I see so the PICTYPE could arbitarily have a length of 10 or 11 depending on the chip and this causes the VER to mismatch and cause this issue, makes sense.
I wonder if a macro could solve this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a new linker parameter -Wl, --fixupoverflow=error that I was hoping could help, but I cannot make it do anything. Even a 'movlw 0x1234' does not cause an error. I think it should.
It is described in the release note.
FF does not work if you enable the extended instruction. A rewritten FF for the extended instruction set would not be any faster or smaller.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I flashed FF onto a PIC18F4520 today using AS from mplabX 6. Forth works on it but the warm word doesn't seem to do anything. Could you guide me on what might be wrong
Several months ago I had flashed the same chip with an older version of FF using mplab 8 and that didn't have this issue.
This is the output of warm
ok<#,ram>
ok<#,ram>
warm
&
ok<#,ram>
ok<#,ram>
warm
&
Hi,
There is a risk that XC8(PIC-AS) compiles faulty code because it does not warn about out of range relative jumps. I complained to microchip about this and it seems the latest 2.40 version has a fix for that. But I have not tried it yet.
Also I have never verified the PIC18Fx520 with PIC-AS.
I just checked the PIC-AS 2.40 and it still does not warn for out of range branches.
But I found a bug in VER. if you change the stringlength to 37 from 38 it may work better.
The PICTYPE string can have two different lengths, 10 or 11. I need to solve that somehow.
Chaning the stringlength to 37 from 38 resolved the issue!
Ah, I see so the PICTYPE could arbitarily have a length of 10 or 11 depending on the chip and this causes the VER to mismatch and cause this issue, makes sense.
I wonder if a macro could solve this issue.
Hi,
Looks like the 2.40 version of PIC-AS aslo has this issue. Just tried rebuilding with it.
Is there some way to detect these RJMPs ? It's funny how it worked well in some old version. XC8 is progressing backwards !
off-topic : Is there any benefit / issue with enabling the extended instruction set?
There is a new linker parameter -Wl, --fixupoverflow=error that I was hoping could help, but I cannot make it do anything. Even a 'movlw 0x1234' does not cause an error. I think it should.
It is described in the release note.
FF does not work if you enable the extended instruction. A rewritten FF for the extended instruction set would not be any faster or smaller.