PIC18F27K42, probably PPS problem

80 views
Skip to first unread message

Oliver Seitz

unread,
Jun 9, 2019, 10:59:56 AM6/9/19
to jal...@googlegroups.com
Hi all!

Has anyone used a chip of that family for anything else than blinking an LED?

I took the risk of starting to try using the UART, but it is (till now) terribly incompatible with jallib...
Then I tried simple PWM, but even that did not work. The PPS thing

INTCON0_GIE     = false
PPSLOCK         = 0x55
PPSLOCK         = 0xAA
asm             BCF PPSLOCK_PPSLOCKED
INTCON0_GIE     = true

 RA0PPS =0b001001       -- CCP1

INTCON0_GIE     = false
PPSLOCK         = 0x55
PPSLOCK         = 0xAA
asm             BSF PPSLOCK_PPSLOCKED
INTCON0_GIE     = true

must have done something, for the Pin_A0 does not switch anymore when assigning values. It simply stays low, however. I did not manage the UART or the CCP1 module to make the LED light up... Maybe someone used that chip and has a working bit of code?

Thanks!

Kiste


Rob Jansen

unread,
Jun 9, 2019, 12:49:38 PM6/9/19
to jallib
Hi Kiste,

Do you have problems with your UART pins? I noticed for some PICs like the 16F19176 that I explicitly needed to assign UART pins to their default value to get them working. I did it as follows:

pps_control_lock(FALSE)               
RC6PPS = PPS_TX1       -- TX1 re-assigned to C6  (default)            
RX1PPS = PPS_RC7       -- C7 re-assigned to RX1  (default)                    
pps_control_lock(TRUE)                

Not sure if that will solve your problem. I could not find any information on this topic but without the PPS the UART did not work. That may also be for other pins.

Kind regards,

Rob

Oliver Seitz

unread,
Jun 10, 2019, 7:08:17 AM6/10/19
to jal...@googlegroups.com
Hi Rob!

Thank you for your reply.

For a first go, I'm now using serial_software, which works with a little addition:

if (defined(INTCON_GIE) == false) then
-- Some newer PICs have INTCON registers numbered differently
   if (defined(INTCON0_GIE) == true) then
      alias INTCON_GIE is INTCON0_GIE
   end if
end if

Shame on me, until now I did not know I had no write access to github repo ;-)

But now using serial_software I should be able to ask the PIC where it hurts :-)

Greets,
Kiste


Am Sonntag, 9. Juni 2019, 16:49:40 UTC hat Rob Jansen <rob...@hotmail.com> Folgendes geschrieben:


--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/792a1f15-0aec-420c-90b6-5c33e6cecd67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rob CJ

unread,
Jun 10, 2019, 8:45:00 AM6/10/19
to jal...@googlegroups.com
Hi Kiste,

I could add your change to the libraries so that it is included in the next release.

I think it is only sufficient to add this statement though:
-- Some newer PICs have INTCON registers numbered differently
   if (defined(INTCON0_GIE) == true) then
      alias INTCON_GIE is INTCON0_GIE
   end if

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 10 juni 2019 13:07
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] Re: PIC18F27K42, probably PPS problem
 

Oliver Seitz

unread,
Jun 10, 2019, 8:51:04 AM6/10/19
to jal...@googlegroups.com
Thank you!

Of course this is sufficient. I got a little paranoid when I realized how different the UART is and started to expect that a whole set of libraries will be needed for future chips ;-)

Greets,
Kiste

Am Montag, 10. Juni 2019, 12:45:02 UTC hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Hi Kiste,

Rob Hamerling

unread,
Jun 10, 2019, 9:18:18 AM6/10/19
to jallib

Sorry, I should have used  'Reply List' (in Thunderbird)

-------- Forwarded Message --------
Subject: Re: [jallib] Re: PIC18F27K42, probably PPS problem
Date: Mon, 10 Jun 2019 15:15:59 +0200
From: Rob Hamerling <robham...@gmail.com>
To: Rob CJ <rob...@hotmail.com>



Hi Rob,


On 2019/06/10 14:44, Rob CJ wrote:
I could add your change to the libraries so that it is included in the next release.

I think it is only sufficient to add this statement though:
-- Some newer PICs have INTCON registers numbered differently
   if (defined(INTCON0_GIE) == true) then
      alias INTCON_GIE is INTCON0_GIE
   end if


This may be helpful for the USART libraries, but what about other libraries and (sample) programs which use INTCON?
It looks better to me to add this alias and aliases for INTCON0 itself and aliases for all INTCON_xxx  bitfields  in the device file.

Regards, Rob.

--
Rob Hamerling, Vianen, NL

Oliver Seitz

unread,
Jun 12, 2019, 11:54:23 AM6/12/19
to 'Oliver Seitz' via jallib

It is probably NO PPS problem... I can output PWM to a pin, and even the uart TX, by routing it through a CLC...

Greets,
Kiste


--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.

Oliver Seitz

unread,
Jun 12, 2019, 12:01:57 PM6/12/19
to jal...@googlegroups.com
Hi Rob!

I would have suggested it that way, if

Am Montag, 10. Juni 2019, 13:18:20 UTC hat Rob Hamerling <robham...@gmail.com> Folgendes geschrieben:



Sorry, I should have used  'Reply List' (in Thunderbird)

-------- Forwarded Message --------
Subject: Re: [jallib] Re: PIC18F27K42, probably PPS problem
Date: Mon, 10 Jun 2019 15:15:59 +0200
From: Rob Hamerling <robham...@gmail.com>
To: Rob CJ <rob...@hotmail.com>

Hi Rob!

I would have backed your suggestion... If there was something like "all INTCON_xxx  bitfields".

Unfortunately, the bitfields of INTCON and INTCON0 do differ:

e.g. 18f26k22
var volatile bit    INTCON_RBIF               at INTCON : 0
var volatile bit    INTCON_INT0IF             at INTCON : 1
var volatile bit    INTCON_TMR0IF             at INTCON : 2
var volatile bit    INTCON_RBIE               at INTCON : 3
var volatile bit    INTCON_INT0IE             at INTCON : 4
var volatile bit    INTCON_TMR0IE             at INTCON : 5
var volatile bit    INTCON_PEIE          at INTCON : 6
var volatile bit    INTCON_GIE_GIEH           at INTCON : 7

vs. 18f27k42
var volatile bit    INTCON0_INT0EDG           at INTCON0 : 0
var volatile bit    INTCON0_INT1EDG           at INTCON0 : 1
var volatile bit    INTCON0_INT2EDG           at INTCON0 : 2
var volatile bit    INTCON0_IPEN              at INTCON0 : 5
var volatile bit    INTCON0_GIEL              at INTCON0 : 6
var volatile bit    INTCON0_GIE               at INTCON0 : 7

Greets,
Kiste

On 2019/06/10 14:44, Rob CJ wrote:
I could add your change to the libraries so that it is included in the next release.

I think it is only sufficient to add this statement though:
-- Some newer PICs have INTCON registers numbered differently
   if (defined(INTCON0_GIE) == true) then
      alias INTCON_GIE is INTCON0_GIE
   end if


This may be helpful for the USART libraries, but what about other libraries and (sample) programs which use INTCON?
It looks better to me to add this alias and aliases for INTCON0 itself and aliases for all INTCON_xxx  bitfields  in the device file.

Regards, Rob.

--
Rob Hamerling, Vianen, NL

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.

Rob CJ

unread,
Jul 1, 2019, 6:49:37 AM7/1/19
to jal...@googlegroups.com
Hi Kiste,

I had a look at this issue and I noticed that it is not sufficient to only add the INTCON alias. The problem is that there are more changes needed and I wonder if we can cover this all with aliases as to be able to cover all other PICs.

For example the library serial_hw_int_cts.jal checks in its interrupt routine PIR1_RCIF == TRUE but this flag is not available for the 18f27k42. There you should use PIR3_U1RXIF so there you need another alias.

Suggestions are welcome.

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: woensdag 12 juni 2019 18:01
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] Re: PIC18F27K42, probably PPS problem
 

Oliver Seitz

unread,
Jul 1, 2019, 12:10:44 PM7/1/19
to jal...@googlegroups.com
Hi Rob,

thank you for having a look :-)

I thought it might be best to think about a completely new backend for the uarts, as they have new possibilities, but are very different indeed from the older versions.

However, as I did not suffice to get neither serial nor PWM signals out of that chip, I would first want to check if the compiler produces the right bytes, it is the first 8-bit-chip ever with 64 memory banks. I had lots of "data check errors" when compiling.

Greets,
Kiste


Am Montag, 1. Juli 2019, 12:49:38 MESZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Rob CJ

unread,
Jul 2, 2019, 6:52:22 AM7/2/19
to jal...@googlegroups.com
Hi Kiste,

As a test I partly rewrote serial_hardware.jal to see if I could get it working with a PIC18F26K42. Initially I tried it with aliases but when errors occur it would not clear all errors so I did a short rewrite of that library. This version is not backwards compatible so it needs to have another name. For now I called is serial_hardware_plus.jal.

The transmission of data is working but the reception is not yet correct. It misses some characters when I type them. In order to get the baudrate correct I needed to set some aliases and a variable to get that correct (see the file serial_hardware_plus.jal). As I mentioned before I needed to set the USART pins to their default location by using PPS otherwise nothing will be output. See the test program for that.

I attached a test program (18f26k42_serial_hardware.jal) and the changed serial hardware library (serial_hardware_plus.jal) . As said the reception of data is not yet correct but it starts to work. I also attached a screenshot as 'proof' 🙂 that at least the transmission is OK.

Hope this helps.

Kind regards,

Rob


Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 1 juli 2019 18:10
18f26k42_serial_hardware.jal
serial_hardware_plus.jal
screenshot.png

Rob CJ

unread,
Jul 2, 2019, 7:50:10 AM7/2/19
to jal...@googlegroups.com
Hi Kiste,

I fixed the issue with the incorrect reception. This library now seems to work OK for the other USART type. I could add it to the new release but I have 2 options:
1) Create a new library file like this. Not sure what to call it.
2) Combine the old and the new file into the old file. The problem here is that it will not make it more readable.

@all. Suggestions are welcome.

Attached the fixed version.

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: dinsdag 2 juli 2019 12:52
serial_hardware_plus.jal

Rob CJ

unread,
Jul 2, 2019, 11:24:16 AM7/2/19
to jal...@googlegroups.com
Hi Kiste,

Sorry for all the e-mail but I decided to apply the changes to the existing serial_hardware library. I tested it for the classic USART with a PIC16F1823 and for the new USART with a PIC18F26K42 and it works for both types.

Attached the library and the sample files. I can add these to GitHub and the next step would be to fix it also for the other serial libraries including the ones that work in an interrupt basis.

Kind regards,

Rob

Verzonden: dinsdag 2 juli 2019 13:50
16f1823_serial_hardware.jal
18f26k42_serial_hardware.jal
serial_hardware.jal

Oliver Seitz

unread,
Jul 2, 2019, 1:13:40 PM7/2/19
to jal...@googlegroups.com
Sorry for Mails?!? 

Sorry for being of so little help atm... :-D

For my current projects I did revert to more "classic" chips to get on. As I could also not get the CVD to work on K42 it seemed to be to much of uncertainty for projects which have a deadline. I'll have a look at your code soon, but I'm not sure I can really test it within the next days.

Greets,
Kiste

Am Dienstag, 2. Juli 2019, 17:24:17 MESZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Hi Kiste,

Rob CJ

unread,
Jul 7, 2019, 8:52:12 AM7/7/19
to jal...@googlegroups.com
Hi Kiste,

I managed to get both the standard serial and interrupt serial driver working for the 18F26k42 but when I was working on the interrupt driven version I also got the data error you mentioned. By lowering the buffer sizes I got rid of it but it seems to be a compiler issue. I also had this issue before with another PIC. 

It took me quite some time to get the interrupt version working since apparently Microchip has introduced vectored interrupts which is by default on. After I found this problem I switched it off in the main program by pragma target MVECEN DISABLED.

I contacted Kyle for the data error problem and I will see if I can find out what causes it. I noticed that the data error problem results in the program not working correctly so it is indeed an error.

Kind regards,

Rob



Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 1 juli 2019 18:10

Rob Jansen

unread,
Jul 13, 2019, 3:33:48 AM7/13/19
to jallib
Hi Kiste,

I am looking at the data error compiler problem with help of Kyle. I did not find the root-cause yet but I found out that it has to do with the 64 banks since I could reproduce it also for another PIC with 64 banks. Kyle suggested a workaround that seems to work.

In the device file of your chip, change:
   pragma  shared             0x0-0x5F,0xF60-0xFFF
to
  pragma  shared             0x0-0x5F,0x3F60-0x3FFF

I still need to find the root cause but at least you can continue.

Kind regards,

Rob
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+unsubscribe@googlegroups.com.

To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/207a0c14-d89e-4098-fb8f-461415c36f06%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+unsubscribe@googlegroups.com.

To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1406706930.483595.1560355311716%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+unsubscribe@googlegroups.com.

Rob CJ

unread,
Jul 13, 2019, 5:57:57 AM7/13/19
to jallib
Hi Kiste,

Some further analysis showed that in the end it is not a compiler error but an error in the Python script that generated the device file. So changing the device file as suggested fixes the problem.

I will fix the Python script and will upload the new device files for the ones that are changed because of the 64 banks. They will then be available in the next bee package. 

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Jansen <rob...@hotmail.com>
Verzonden: zaterdag 13 juli 2019 09:33
Aan: jallib
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

To post to this group, send email to jal...@googlegroups.com.
Visit this group at https://groups.google.com/group/jallib.
Reply all
Reply to author
Forward
0 new messages