#PIN_SELECT problems

bela · Joined: 31 Aug 2008 Posts: 27 Location: Bedford, BEDS UK

Hi All,

I have an issue mapping my SPI to my RPx pins.

Chips tried: 24FJ64GA002, dsPIC33FJ64MC802, 33FJ12GP202
Compiler: PCD 4.097

Ttelmah · Joined: 11 Mar 2010 Posts: 19505

On the first of those chips at least, the SPI, is _not_ software selectable. It is relocatable to two different pin pairs, using a fuse. I2C1SELA or I2C1SELD.

Didn't look at the other chips.

Best Wishes

bela · Joined: 31 Aug 2008 Posts: 27 Location: Bedford, BEDS UK

Hi thanks for your reply.

According to the family data sheet the SPI is software selectable.

Table 10-2 shows the Inputs (for SDI)
and 10-3 show the Outputs (CLKOUT and SDO)

The same tables show U1TX and U1RX.

or have I mis-understood it?
_________________
There are 10 types of people in this world; those who understand binary and those who don't.

Ttelmah · Joined: 11 Mar 2010 Posts: 19505

They are using 'mixed meanings' for the phrase 're-mappable pins'. Most are mappable to any of the RP pins, but the SPI is not.

If you look at table 1-2, the SPI lines are shown as only mappable to the SCL1/2 SDA1/2 SDI1/2 pins or the ASCL1/2 ASDA1/2 ASDI1/2 pins, with the selection done using the fuses already mentioned. They are 're-mappable', but _not_ to the general re-mappable peripheral pins.
So the UART is mappable using #pin select, but the SPI can only be mapped to the two alternate locations using the fuses.

Now I agree the pages later in the stuff dealing with the re-mappable pins disagrees. One or the other is a data sheet error. The compiler is treating the first as 'right', and the fuses shown also say this is right (the alternate is shown here too).
To further confirm this, MPLAB, does not have the re-mapping register for the SPI implemented.
I'd suspect a generic bit of data sheet has been cut and pasted...

Best Wishes

jeremiah · Joined: 20 Jul 2010 Posts: 1346

I didn't check on the two other chips, but the pic24fj64ga002 does have SPI on the RP pins. #pin_select is appropriate for SPI on the first chip (I didn't check the other ones). Only I2C is not remappable past those specific pins.

You either need to upgrade your compiler or there is more to your code than you are showing us. I just tossed those pin selects into one of my pic24fj64ga004 programs, changed my include to the 002 and it compiles fine. This is with both 4.140 and 5.011

EDIT: This is one reason the forum rules state you provide a complete solution (Which would have been easy to do in your case since all you would have needed was a blank main to show this issue). As it stands, I am mostly certain it is your compiler revision, but you need to follow forum guidelines so we can better help.

EDIT: Looking at the data sheet for the other two pins, I am pretty confident they are the same (PIN_SELECT is correct).

jeremiah · Joined: 20 Jul 2010 Posts: 1346

I wanted to separate this post out.

Ttelmah · Joined: 11 Mar 2010 Posts: 19505

I can confirm it is a version problem.

If you look at the device database for this chip in this version, the compiler only 'knows' about what it thinks is an I2C/SPI port, with the pins remapped by fuses.
In common with quite few of these later chips, the SPI is actually a separate peripheral, but this compiler doesn't know about it, and so doesn't know that this is re-mappable...
Support for the separate peripheral is there about twenty compiler versions later.

Best Wishes

bela · Joined: 31 Aug 2008 Posts: 27 Location: Bedford, BEDS UK

Thanks for the replies.

Sorry for not posting full code. However, it's very close to the example you supplied except #use SPI commented out and printf ("Test msg");

The sample code you supplied will not compile:

Invalid pre-processor directive: invalid pin (chip) x3
and
SPI Module not assigned, use #PIN_SELECT

To be honest, I usually do bit banging when it comes to SPI, that's why I haven't come across this yet.

This is fairly fundamental so if it's a compiler bug, I would expect to get a fix for free. What are the chances of that?

Many thanks for all help.
Darren.
_________________
There are 10 types of people in this world; those who understand binary and those who don't.

alan · Joined: 12 Nov 2012 Posts: 357 Location: South Africa

Good luck with that. Maybe CCS has changed. When I started with v3 and just bought it, I submitted bug reports about twice weekly, after 3 months of this, I still had no working complier and CCS just told me that my maintenance has run out, so sorry.

So I just worked around the bugs for about 2 years, before I finally decided that I would upgrade as I needed new chip support.

Regards

Ttelmah · Joined: 11 Mar 2010 Posts: 19505

I'd say 'no hope' on a bug this old.
The point is that if you as a user had encountered this a few weeks/months after buying, then 'yes'. However for a compiler well over 3 years old. Not really.

It was fixed soon after. The code compiles and works on 4.104.
Given that, if you ask very nicely, they might possibly be prepared to let you upgrade 'cheaply' to a version like 4.141.

It goes back also to the 'takes about ten versions for CCS to get things to work'... Support for these chips, was only added a very few versions earlier.

Best Wishes

bela · Joined: 31 Aug 2008 Posts: 27 Location: Bedford, BEDS UK

To be honest, so many CCS bugs and issues have tripped me up / delayed projects that I'm about to switch to XC8 / XC16 from the Microchip.

Doesn't look like we'll need the extra optimisation which will set up back a couple of grand.

However, If I don' get time to learn XC before the next software project comes along, it'll back to go old CCS PCD!

I mean, we sell our embedded programming knowledge as a product for money. If the customers knew what a joke our chosen compiler is...

Thanks everyone who helped.
_________________
There are 10 types of people in this world; those who understand binary and those who don't.

bkamen · Posted: Mon Sep 16, 2013 10:09 am

Ttelmah · Joined: 11 Mar 2010 Posts: 19505

Yes.

XC, simplifies the problems for itself, but not trying to be too smart.
CCS does a huge amount for you, but by doing so, creates extra problems.

Worth realising that you can directly access the pin selection registers and not use #PIN SELECT at all. This is how you have to do it in XC, and it works in CCS.

Best Wishes

bela · Joined: 31 Aug 2008 Posts: 27 Location: Bedford, BEDS UK

Agreed but some of the things wrong here are pretty fundamental.

And, as you all predicted, CCS have just said it's an old version of the compiler and refused to help me any further.

If I sent out a PCB design with important sections of the circuit not working and then only respond by saying, "you can buy the new version", we wouldn't be in business.

Agreed on MPLABx. only saving grace for me is that it runs on Linux.

Of course, Microchip have introduced the peripheral library which seems pretty tidy but is also in its infant stages so I hope it gets better as I don't have any intention of learning hundreds of register names.

Thanks again.
_________________
There are 10 types of people in this world; those who understand binary and those who don't.

Douglas Kennedy · Joined: 07 Sep 2003 Posts: 755 Location: Florida

This remapping via #pin_select is constrained.
First the chip has to support it..I know it is too obvious to be useful advice but it is necessary. Not all pins on a chip are remappable.
Second it must have a RP pin designation by Microchip. RP comes in two forms RPI and just RP.
Third again it may be too obvious but a RPI pin can't be remapped to an output.
EX the spi SDO ( MOSI) can't be mapped to a RPI pin.
Then of course the SPI slave must be electrically compatible.
On 3v parts some remappable pins are 5v tolerant for input some aren't.