dsPIC30F preventing floating input issues

[Zeyneb]

Anyone willing to help me a little to ensure I'm doing it right. I'll describe a clear as I could.

My dsPIC30F3012 is used to write samples to two external DACs with the SPI peripheral. However I don't need to read anything back from the DACs, so my SDI pin on the MCU is unconnected. The DACs don't have serial out pins anyway.

I know that the SPIEN bit in the SPI1STAT register configures the pins related to SPI. Some of them can be disabled like SDO and SS. But not SDI. However it seems that the ADPCFG register (A/D Port Configuration Register) overrules the setting of SPIEN. I mean if the SDI pin is configured for analog input (default actually), SDI is non-functional and the digital buffer is disabled and it is acceptable to have the pin floating.

It would be really nice if someone can confirm this. I don't need to use the SDI for general purpose IO, I just want to be sure if it can be left floating with my initialization code.

The whole idea behind ADPCFG is by default set for analog inputs is to make it okay to have these input floating, right?

Best regards,
Zeyneb

[Kalvin]

If the SDI-pin and its associated GPIO-pin has a pull-down bit available, you can activate the on-chip pull-down.

[Ultron]

Yes, you can leave the SDI pin not connected. This is usual in SPI devices than they not return any value, just like DAC

In any case the pin will be set as SDI input by the driver (SPIxCON1 configuration register). Simple you not use it, or also connect it to GND

[Howardlong]

The whole idea behind ADPCFG is by default set for analog inputs is to make it okay to have these input floating, right?

I've never heard a justification for Microchip making GPIO pins analogue by default, but this is universal across the PIC range in my experience, although to confuse things the register naming is not, and sometimes it's indexed on analogue port number (AN#) and sometimes on GPIO port number (e.g. RA#).

It is generally not considered good practice to leave unused inputs floating because as being high impedance they can easily go into oscillation. I recommend this Compiled Tips and Tricks document from Microchip, namely section 2 tip 3.

[Kalvin]

If the SDI-pin and its associated GPIO-pin has a pull-down bit available, you can activate the on-chip pull-down.

I looked at the dsPIC30F3012 datasheet and the SDI-pin is also a CN7-pin. The CN-pins have on-chip, software enabled pull-ups. The pull-up CN7PUE might be usable although the CN7-pin is not configured as change-notification pin.

The SDI-pin is also a PGC-pin used for programming, so you could also connect the pin to GND using a suitable resistor, if you do cannot or want to use the on-chip pull-up CN7PUE.

[Howardlong]

If the SDI-pin and its associated GPIO-pin has a pull-down bit available, you can activate the on-chip pull-down.

I looked at the dsPIC30F3012 datasheet and the SDI-pin is also a CN7-pin. The CN-pins have on-chip, software enabled pull-ups. The pull-up CN7PUE might be usable although the CN7-pin is not configured as change-notification pin.

The SDI-pin is also a PGC-pin used for programming, so you could also connect the pin to GND using a suitable resistor, if you do cannot or want to use the on-chip pull-up CN7PUE.

Agreed. If the OP _is_ using PGC, it should be noted that PGD is on the same pin as SDO, so although the OP may be using the pins for ICSP, I would doubt they're using these pins for debugging. If that's the case then using the internal pull ups seems a pretty reasonable idea as a hardware reset places these pins resets the weak pull ups and places the pins in Hi-Z anyway.

The internal weak pull ups are ITRO 50k or so, but tolerance is pretty dire, according to the data sheet they could be anything between 12.5k to 100k.

As a general rule PGC/PGD should not be used with permanent pull-ups as the programmers rely on internal 4.7k pull downs, so there could be conflict depending on the use of these pins in circuit. There are secondary debugger pins on this device.

[Zeyneb]

Thanks to all for your contributions. I think I'm going for Kalvin's suggestion to use a 47k pull-down on the SDI line. Yes, this is also my PGC programming line. In the ICD3 documentation they advised against pull-ups there but they say nothing about pull-downs. I tested if the programming and verify did work with an 3k3 pull down on PGC and it did. So, I think I'm fine with the 47k.

Strange thing is that the "dsPIC30F Family Reference Manual" say something that you CAN use the SDI port as an output when you don't use it in the SPI bus. Version DS70046E of this document paragraph 11.3.1.2 (page 256).

I quote:

"For example, the SPI module can be configured for Master mode in which only the SDO pin is
required. In this scenario the SDI pin can be configured as a general purpose output pin by clearing
(setting to a logic "0") the associated TRISx bit."

So I tried this but I didn't got it working. I tried to set the corresponding TRIS bit to 0 and then configure the SPI IOs with enabling SPIEN in the SPI1STAT register. In the main loop I tried toggle the SDI pin with writing to the LAT register of RB5. SDI stayed 0. Then I first did SPIEN and then TRIS. Still 0. So shoot me, I'm lost. Or we have another silicon bug?

Greetz, Zeyneb

[Howardlong]

I can't help you directly with your question right now, but I just checked my stock and I have your device in stock (both -20 and -30 not that it will make much difference). If you post your code and basic schematic I can see if I can reproduce your problem and see if I can give you pointers.

[Zeyneb]

Hi Howard,

Thanks for your willingness to help me. But I've decided to move on with my project. So, I'm just using the physical 47k pull-down on the SDI line.

I still think semiconductor companies can do a lot better about their documentation. To share a little about the reason why some feature was implemented (example driven) is a lot better to understand than those descriptions after something is implemented.

If you want you can just try if you can configure the SDI pin some way and write something to the SDI pin, to see if it can be used as an output while using the SPI peripheral at the same time.

Best regards,
Zeyneb