SEROUT2 broken on 18F4620 ?

[Kamikaze47]

If the default configs work, is there any reason you cant just use them? If there are any configs that you definitely need to change from default, then simply change them one at a time so you know if one of them breaks it.

[mr.sneezy]

I like to know whats going on, so I did it the hard way...

This config line kills Serout2 functionality.
@ __CONFIG _CONFIG4L, _DEBUG_OFF_4L & _LVP_OFF_4L & _STVREN_OFF_4L

This line restores it.
@ __CONFIG _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _XINST_OFF_4L

Drilling down to individual config parameters, if I add this one to my original list Serout2 works again.
& _XINST_OFF_4L

The datasheet refers to this as an Extended Instruction set enabling bit. I read a bit about it, and it's use is way beyond my comprehension.

What the ?
And why does it just break the Serout2 command and not everything else in PBP too ?

It's days like these I really wonder why we bothered coming out of caves and inverting the wheel anyway, it would have been much less pain just staying in a nice warm cave

[Acetronics2]

Hi, Sneezy

Here's the reason ...

PBP defaults :

INCLUDE "P18F4520.INC" ; MPASM Header
;__CONFIG _CONFIG1H, _OSC_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
;__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
;__CONFIG _CONFIG3H, _CCP2MX_PORTC_3H & _PBADEN_OFF_3H & _LPT1OSC_OFF_3H & _MCLRE_ON_3H
;__CONFIG _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _XINST_OFF_4L

so, "PBP" is supposed to clear this config bit ... but you remmed those lines :

BUT ...

MPASM defaults it to OFF ...

Sooooo, What happend ??? how did it turn on by itself ???

Conclusion ... do not forget to explicitly turn OFF XTINST in your config.

Further explanations can be found in Datasheet $24 ( a bit over my own head ...I admit ! )


Alain

[mr.sneezy]

Thanks Alain,
BTW, do you think I've just had a run of strangely bad luck with my programming, or does it come this hard for you too ?

(By bad luck I mean the fact that this config only broke Serout2 in my code but apparently nothing else)

[Acetronics2]

BTW, do you think I've just had a run of strangely bad luck with my programming, or does it come this hard for you too ?

(By bad luck I mean the fact that this config only broke Serout2 in my code but apparently nothing else)

...
The existence of extra-terrestrians hasn't been proved nor denied ...

SO, ... I do believe you were unlucky, trying desesperatly some " uncontrolled " receipes

Sometimes I have surprises too ... just remember what to do not to have to face it again ...


BUT I never could explain I dreamed of situations that I faced several years LATER ...
There are still great mysteries in our lives ...

And I do think it's much better like that !!!

Seriously ... someone like Darrel, who learnt the internals of PBP, maybe could explain what happens when XTENDED commands are enabled.

I Personnaly do not have time to, and my Pics use being Hobby dedicated ... I prefer learning other things ... or build toys for my Daughters.

Alain

[Bruce]

PBP places all of its system variables in ACCESS RAM on the 18F type. When you have the extended instruction set enabled, this changes how all PBP system variables in the range of 00h to 5Fh in ACCESS RAM are accessed.

With extended instruction set enabled, FSR2 is used as the pointer to an area in RAM, and the address embedded in the instruction itself, that is trying to write to ACCESS RAM from 00h to 5Fh, is the literal "offset" into the RAM area pointed to by the value in FSR2.

So ACCESS RAM from 00h to 5Fh is no longer directly accessible without using FSR2 as the base address pointer.

Example:

Say a PBP system variable R1 is in ACCESS RAM at location 2. Now say FSR2 has a value of 2. When PBP tries to directly load a value into R1, it actually gets placed in location 4. This happens because location 2 which would be the DIRECT address to R1 in ACCESS RAM is used as the literal "offset" and added to the value in FSR2 to get the final RAM address.

Just clearing FSR2 somewhere in your program just isn't going to work. Several PBP library routines and a TON of PBP macros use FSR2.

Also - it's a good idea to keep the _XINST_OFF_4L config option in there.

All config options are just numbers that get ANDed together by the assembler. If you leave one out, like _XINST_OFF_4L, which includes a value of BFh that gets ANDed with other config options for CONFIG4L, you end up with _XINST_ON_4L by default.

Here's an example;

These are pre-defined CONFIG4L options in your P18F4620.INC file.

 
;----- CONFIG4L Options --------------------------------------------------
_STVREN_OFF_4L  EQU H'FE' ; Disabled
_STVREN_ON_4L   EQU H'FF' ; Enabled
_LVP_OFF_4L     EQU H'FB' ; Disabled
_LVP_ON_4L      EQU H'FF' ; Enabled
_XINST_OFF_4L   EQU H'BF' ; Disabled
_XINST_ON_4L    EQU H'FF' ; Enabled
_DEBUG_ON_4L    EQU H'7F' ; Enabled
_DEBUG_OFF_4L   EQU H'FF' ; Disabled

Note that XINST is bit # 6 in CONFIG4L. A value of 1 in bit position # 6 = enabled.

Take any value "ON or OFF" above for STVREN, LVP, and DEBUG. AND them together, then look at the result. The value you end up with after ANDing any 3 options is the value that gets placed in CONFIG4L.

Leaving XINST "on or off" out leaves bit # 6 set, and extended instruction mode enabled.

The same goes for all other config registers. If you leave one option out, you may not be getting all config settings like you might expect - due to the AND result of all the ones you 'did' include.

[mr.sneezy]

Much appreciated, as it is a full answer to the question.

To reiterate though for my benefit, and maybe others at my low level of understanding.

If I use assembly style configs, either in my code or the PBP PIC.inc defaults, if I need to use a non PIC default config setting I should also add all other config values associated with that particular register, to make sure they don't get changed from what I expect ?