Peripheral Pin Select for 24FJ256GA106

[kerplatz]

I have a problem that CCS does not address. The processor that I am coding on is the pic24FJ256GA106. This is what the data sheet says
"PIC24FJ256GA110 family devices support a larger number of remappable input only pins than remappable input/output pins. In this device family, there are up to 32 remappable input/output pins, depending on the pin count of the particular device selected; these are numbered, RP0 through RP31. Remappable input only pins are numbered above this range, from RPI32 to RPI45 (or the upper limit for that particular device)."
The chip has 3 SPI hardware on it, but I cannot get it to write anything including clock to the pins I want to use which are 3 of the remappable pins. The function get_env("SPI") returns a 1 so I know CCS can see it. When I do the same for the clock pin, get_env() reports '0'. So I can't find anything in the documentation or on this forum that addresses how to configure this pins. It could be as simple as writing to the registers mentioned in the datasheet for the chip and then setting up the SPI with #use spi() right after the pin configuration. OR, maybe CCS has some weird way of doing what I need to do.
If I was not using CCS, I would just follow the datasheet, but I want to do it the CCS way, if there is one. Non-remappable devices that I use work fine. I am pretty sure that the CCS code that I write is just not getting connected or pointed to the correct pins. Thanks.

[temtronic]

The first place I'd go is to CCS themselves. While many on this forum may use that PIC( I don't),you have to remember the hundreds of new PICs that come out yearly and how ANYONE can keep track of this feature or that pin or whatever PIC is ,well, beyond me.
I've had CCS PCM since v2.453+- and evert time I asked a question or posed a problem, they got back, fairly fast too.
When you consider the average PIC these days has 400+ pages of data associated with it, it's easy to see how the odd thing or two gets by CCS. I don't know how many they employ or how they actually test their compilers on new PICs 'features' but it has to be mind numbing to us 'older gents'.
It's one of the reasons I've stuck with just one PIC for a few years, tried and true, stable, does 100% of what is needed.

Jay

[dyeatman]

Does this help?

http://www.ccsinfo.com/forum/viewtopic.php?t=51164&highlight=pinselect
_________________
Google and Forum Search are some of your best tools!!!!

[kerplatz]

Yes. I had to read all the way to the end, but I did get my question answered. Thanks everyone.

[Ttelmah]

First look at the CCS header file for the chip.
This lists what pins can be selected, and what peripherals.
Then look at the top few posts here in the forum, there is one 'sticky' which shows an example of using the re-mappable peripheral, and particularly how to use the peripheral name to set it up.
CCS doesn't use the RP names. Just the actual pin names. It translates these for you.

A caveat you may meet later, - not on this peripheral, but on some with bi-directional use (I2C for example), on some chips you have to setup both the output device and the input device separately...

The following compiles for your chip (with a suitable header), and on a similar chip gives clock and data on the expected pins.

[kerplatz]

Ttelmah,

The code you provided is essentially what I am doing. I have many other things going on, but the SPI is configured like your example. I am watching the SPI lines with an analyzer, and they just stay low. I think I will create a new project with just the SPI to eliminate any conflicts. Do you have to use the spi_init() to make SPI work? Thanks.

[Ttelmah]

No. spi_init, is used if you want to enable/disable the port. It's like the setup_uart command for the UART. You can change the baud rate, and disable the port if required. You use #USE SPI, with the 'NOINIT' option, then when you want to use the port, use spi_init. By default (without this option), the port is automatically initialised at the start of the code.
The code works as posted.

Before fiddling, try setting up software SPI on the pins you are using (just give the pin names to the #USE SPI command, instead of SPI1). if this doesn't work, you have a hardware problem.

Also, what pins are you using?. Remember a lot have default peripherals on them that may have priority over the SPI. And then the obvious other question 'what compiler version'?.

[kerplatz]

I want to give my final feedback for this thread. The problem did turn out to be hardware. The solution was to remove a solder bridge on a component where the spi clock was shorted to the CS line for that component. Now the problem make perfect sense. Thanks for all the help.