chipKIT® Development Platform

Inspired by Arduino™

Fubarino SD Pins 5,6

Created Wed, 22 Jan 2014 01:30:50 +0000 by mikes


mikes

Wed, 22 Jan 2014 01:30:50 +0000

Fubarino SD 1.4 (PIC32MX795F512H) Using IDE Version 20120903 Pins 5 and 6 work as digital I/O if I upload the same sketch using Version 20130715 they don't work as inputs. I assume this has something to do with the changes to the core and that disabling secondary oscillator was removed. This line is in the old version of wiring.c and not the new one

#pragma config FSOSCEN	=	OFF

Is there any way to disable it from within a sketch so that those pins can be used?


majenko

Wed, 22 Jan 2014 10:52:17 +0000

That line will have had no effect. That setting is confugured in the bootloader, not the sketch, and the setting in the sketch would be completely ignored.

That is, unless you're not using a bootloader and are programming your sketch yourself, in which case you're on your own ;)

What there is in wiring.c though is:

//OSCCONbits.SOSCEN = 0;

which may be where the change is.

Adding

OSCCONbits.SOSCEN = 0;

to your setup() function should disable the secondary oscillator.


mikes

Wed, 22 Jan 2014 17:52:56 +0000

Sorry but adding that did not fix the problem, the pins still read as zero on the newer version of MPIDE.

Here is some code that has the problem.

#define us8 unsigned char

void pinsToNibbleInit(us8 pin_b3, us8 pin_b2, us8 pin_b1, us8 pin_b0)
{
  pinMode(pin_b3,INPUT);
  pinMode(pin_b2,INPUT);
  pinMode(pin_b1,INPUT);
  pinMode(pin_b0,INPUT);
}

us8 pinsToNibble(us8 pin_b3, us8 pin_b2, us8 pin_b1, us8 pin_b0)
{
  us8 nibble;
  nibble = digitalRead(pin_b0) << 0 |
	        digitalRead(pin_b1) << 1 |
	        digitalRead(pin_b2) << 2 |
	        digitalRead(pin_b3) << 3;
  return nibble;
}

void setup() {
  OSCCONbits.SOSCEN = 0;
  Serial.begin(115200);
  pinsToNibbleInit(4,  5,  6,  7);
  delay(3000);
  Serial.println("starting...");
}

void loop() {
  us8 a;
 
  a = pinsToNibble(4,  5,  6,  7);
  Serial.println(a, BIN);
  delay(100);
}

majenko

Wed, 22 Jan 2014 21:06:10 +0000

My Fubarino SD (795 version) works fine on pins 5 and 6 using UECIDE, which uses the git version of the core, so is as up to date as (if not more so than) 20130715.

There is a new test version just released - check the announcement from earlier in this forum - you might like to try that out.


mikes

Wed, 22 Jan 2014 22:26:15 +0000

That code also does not work with mpide-0023-windows-20140121-test


majenko

Wed, 22 Jan 2014 23:06:31 +0000

Works perfectly fine for me under Linux. Are you certain that it STILL works under 20120903, and that you haven't broken your board?

Have you tried it under UECIDE to see if it works?


mikes

Wed, 22 Jan 2014 23:55:20 +0000

Yes it STILL works under 20120903. I just tried it under UECIDE it still fails. I even tried a different Fubarino SD with the same results. My computer is Windows 7


mikes

Thu, 23 Jan 2014 01:16:13 +0000

In Board_Data.c new there is this function

void _board_init(void) {
	/*	Turn off Secondary oscillator so pins can be used as GPIO
	*/
	OSCCONCLR	=	_OSCCON_SOSCEN_MASK;
}

In the old Board_Data.c it included a unlock (from plib I think) which was removed in the new version.

void _board_init(void) {
	//*	Turn Secondary oscillator off
	
	unsigned int dma_status;
	unsigned int int_status;
	
	mSYSTEMUnlock(int_status, dma_status);

	OSCCONCLR	=	_OSCCON_SOSCEN_MASK;

	mSYSTEMLock(int_status, dma_status);	
}

I found the referenced code and added it with the unlock to the new Board_Data.c file and it now works

void _board_init(void) {
        __inline__ int __attribute__((always_inline)) DmaSuspend(void)
	{
		int suspSt;
		if(!(suspSt=DMACONbits.SUSPEND))
		{
			DMACONSET=_DMACON_SUSPEND_MASK;		// suspend
			while((DMACONbits.DMABUSY));	// wait to be actually suspended
		}
		return suspSt;
	}
         __inline__ void __attribute__((always_inline)) DmaResume(int susp)
	{
		if(susp)
		{
			DmaSuspend();
		}
		else
		{
			DMACONCLR=_DMACON_SUSPEND_MASK;		// resume DMA activity
		}
	}

#ifdef _DMAC
	#define	mSYSTEMUnlock(intStat, dmaSusp)	do{intStat=INTDisableInterrupts(); dmaSusp=DmaSuspend(); \
						SYSKEY = 0, SYSKEY = 0xAA996655, SYSKEY = 0x556699AA;}while(0)
	#define mSYSTEMLock(intStat, dmaSusp)	do{SYSKEY = 0x33333333; DmaResume(dmaSusp); INTRestoreInterrupts(intStat);}while(0)
#else
	#define	mSYSTEMUnlock(intStat, dmaSusp)	do{intStat=INTDisableInterrupts(); \
						SYSKEY = 0, SYSKEY = 0xAA996655, SYSKEY = 0x556699AA;}while(0)
	#define mSYSTEMLock(intStat, dmaSusp)	do{SYSKEY = 0x33333333; INTRestoreInterrupts(intStat);}while(0)
#endif	// _DMAC
	//*	Turn Secondary oscillator off
	
	unsigned int dma_status;
	unsigned int int_status;
	
	mSYSTEMUnlock(int_status, dma_status);

	OSCCONCLR	=	_OSCCON_SOSCEN_MASK;

	mSYSTEMLock(int_status, dma_status);
}

I don't know how yours could work if the register needs unlocking and it was not being done :?


majenko

Thu, 23 Jan 2014 10:25:51 +0000

My guess is that yours is using a different bootloader to mine.

The bootloader I use on mine has:

#pragma config FSOSCEN  = OFF                                   // Secondary oscillator enable

That is the "official" chipKIT bootloader compiled from the github repository.


mikes

Mon, 27 Jan 2014 21:17:38 +0000

The two boards I tested were about a year old. I guess the official boot loader has changed in that time.

I tested a new board and it worked without any modifications.

There should be a place with warning about changes that break compatibility.


guymc

Mon, 27 Jan 2014 22:05:16 +0000

Hi mikes,

Thanks for chasing down this difficult problem.

I certainly agree that a warning (at least) is called for. New code should not break backward compatibility, except when absolutely unavoidable.

I'll follow up on this, and make sure it gets fixed in an upcoming release.

Cheers


KeithV

Mon, 27 Jan 2014 23:01:36 +0000

Sounds like you are using a really really old bootloader. In the new bootloader we specifically unlock the processor and leave it unlocked.

I forget, but it is possible that the original bootloader of many years ago locked the processor and required the unlock code.