CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC18LF26K83, CAN, and PPS (v5.091) [Solved]

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PIC18LF26K83, CAN, and PPS (v5.091) [Solved]
PostPosted: Tue Sep 01, 2020 6:43 pm     Reply with quote

Has anyone managed to get CAN working on one of these things? I have CANRX connected to PIN_B2 (which is the default for PPS) and CANTX connected to PIN_B1. CANTX doesn't have a default; in fact, even though the processor has only one CAN peripheral, there exists a CANTX0 and CANTX1 in the list of PPS remappable outputs. I can't find anything definitive in the Microchip documentation (data sheet and a migration guide I found which outlines what to do when porting from 18FxxK80 to the 'K83). I assume that CANTX0 is the proper output, but I tried CANTX1 as well with absolutely no luck.

That aside, I do have CAN reception working. I cannot transmit any CAN packets.

In frustration I changed the PPS1WAY fuse to NOPPS1WAY so that I could try the pps_select() function and have a look at the disassembly. From what I can gather, the compiler is accessing the wrong page (and wrong register) for the PPSLOCK register. I gave up trying to trace what it was doing beyond that and instead hard coded the absolute address of the PPSLOCK register and the RB1PPS register as opposed to using the getenv() function after using said function didn't allow me to transmit CAN packets.

Pretty much at my wits end with this.


Last edited by newguy on Wed Sep 02, 2020 2:17 pm; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 12:05 am     Reply with quote

The 'standard' way to handle PPS and CAN on the CCS drivers, is to do this:
Code:

#define CAN_RX_PIN PIN_B2
#define CAN_TX_PIN PIN_B1
#include <can-18xxx8.c>

This then uses #pin_select to select the pins you have specified.

Now doing this with your chip and compiler version, the code generated
(at the start of main, for PPS), is:
Code:

000E:  MOVLB  E
0010:  MOVLW  55
0012:  MOVLB  3A  //Bank 3A
0014:  MOVWF  xBF //0x3ABF - correct PPSLOCK register
0016:  MOVLW  AA
0018:  MOVWF  xBF
001A:  BCF    xBF.0 //clear PPSLOCKED bit
001C:  MOVLW  0A
001E:  MOVWF  xED
0020:  MOVLW  33
0022:  MOVWF  x09
0024:  MOVLW  55
0026:  MOVWF  xBF
0028:  MOVLW  AA
002A:  MOVWF  xBF

Which is accessing the correct PPSLOCK register.

So the default code does seem to be setting the register correctly.

Now I must admit the TX0/TX1 bit is odd. However the migration guide
says that TX1, is the equivalent of TX2 on the '80, and the default CANTX
is TX0. The CCS code used as I show, uses:

#pin_select CANTX0 = CAN_TX_PIN

So is using TX0.

Now using the pin_select() operation, does seem to access the wrong bank.
It seems to use bank 39, instead of 3A. Compiling on the current compiler
correctly uses 0x3A. So there is a compiler issue with your version and
the 'inline' pin_select function.
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 8:47 am     Reply with quote

I installed 5.093 (latest version I have) and it's not any better. I can see at the top of main that the

Code:
#pin_select CANTX0 = PIN_B1
#pin_select CANRX = PIN_B2


Are accessing the proper registers but even on this version the pin_select() function is completely out to lunch in terms of the registers it accesses.

All that said, my CAN driver is quite heavily customized, but it is still, at heart, based upon the CCS can-18xxx8.c. I cannot send CAN messages.

I even had a look at what module(s) default as output to PIN_B1: the CWG2 and SPI2 (even though the processor only has ONE SPI peripheral) and added code to disable CWG2 and the SPI module (not SPI2 because the PIC doesn't have a second SPI module but that's what the datasheet's pin allocation table says). Still no love.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 10:15 am     Reply with quote

Once a PPS selection is done it overrides any existing peripherals.

Can confirm I just tried 5.093, and it still uses the wrong addresses.
The fix is in 5.094 unfortunately....
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 2:17 pm     Reply with quote

Combination of one wrong register address definition, a somehow corrupted CCS installation, and a CCS acknowledged issue with their pps_select() function all added up to about one full day (and one sleepless night) of headaches for me. Solved now.

As an aside: has anyone else noticed that windows 10 and CCS don't seem to get along from time-to-time? This is now the 3rd time in the last year or so on 2 different machines that my CCS installation just starts to behave really badly. Like making code changes and compiling those changes, but the contents of the output hex file not actually changing...?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Sep 03, 2020 4:07 am     Reply with quote

I think there is an issue that CCS still likes to talk at times to it's files
in the program files directory, which can cause permission problems.
This affects quite a few things like registry keys as well. Basically if you
attempt to write to a location that Windows considers 'protected', the write
will fail. If the virtualisation is enabled, it instead
directs the write to a shadow 'copy' of the required location, stored in the
user data.
This is File & Registry virtualisation.

If your system has this virtualisation disabled, this could result in data loss
(since Windows 10 will not allow the write to occur).
This is in:

\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

run secpol.msc
local policies tab
security options tab.

Then look for
'User Account control Virtualize file and registry write failures'.

This must be enabled to allow applications that use the older Windows
security options to work. If it isn't, turn it on. Reboot after enabling.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Sep 04, 2020 1:08 pm     Reply with quote

Ttelmah wrote:
\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Ttelmah, can you tell me how to get to this Computer Configuration folder
or window ? I've searched all over my Windows 10 PC and I can't find it.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 12:03 am     Reply with quote

I say how to do this in the lines after.

It's not a 'folder', it's part of the Windows configuration data.

secpol.msc accesses it as outlined.

They are actually stored in a combination of places. The registry, and
%WINDIR%\system32\grouppolicy

You can also access them using gpedit.msc, instead of secpol.msc, and
then the location is the whole string given.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 5:36 am     Reply with quote

One day Mr. T's head will explode from all the data that's in it !!! Laughing
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 8:01 am     Reply with quote

I have days at work, where I say, that I need to go and put my head
in a bucket of cold water. It feels like it wants to explode....
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 10:13 am     Reply with quote

Weird, virtualization is actually enabled on both my machines. No idea why my installations get corrupted from time to time.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 12:00 pm     Reply with quote

Me too. Already enabled.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Sep 05, 2020 12:21 pm     Reply with quote

OK.

I have never seen this issue. Have currently about twenty copies of the
compiler all installed in separate directories, and can use them from
Win XP, Win7, Win10 32 & Win 10 64.
Only difference is that these are all 'virtual' copies of Windows, since I run
in a Mac. I also though have a copy on my laptop, which is also Win 10,
and this too has never displayed an issue. The virtualisation should not
change anything, the Windows all run just as normal versions.
However one difference, is in all cases I locate the actual source files
in my own 'source data' directory, and then have sub-directories for each
project. This is owned by me, and has R/W permissions for me. I never
leave the sources in the default/standard locations.
I suspect it has to be a Windows permissions issue of some sort. These
are (unfortunately) sometimes quite common, since Windows shifted to
trying to tighten it's security behaviour up.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group