mapPps issues

Created Tue, 11 Mar 2014 11:46:07 +0000 by GrahamM242

GrahamM242

Tue, 11 Mar 2014 11:46:07 +0000

I've spent my time scratching my head over why I'm having such issues mapping peripherals to pins. I'm using an MX150 on a breadboard, with caroper's boot loader - I've created the requisite Boards_Defs.h/Board_Dad.c files and modified the boards.txt file to include them.

However, I note that my PPS mapping for output doesn't appear to work correctly. If I try mapping U1TX to device pin 16 (which is valid according to the datasheet) using

mapPps(12,PPS_OUT_U1TX);

, mapPps returns false! Just for completeness my mapping for output pins looks like the following:

const uint8_t digital_pin_to_pps_out_PGM[] = {
	_PPS_OUT(_PPS_RPA0R),		//	0  RA0		VREF+/CVREF+/AN0/C3INC/RPA0/CTED1/RA0
	_PPS_OUT(_PPS_RPA1R),		//	1  RA1		VREF-/CVREF-/AN1/RPA1/CTED2/RA1
	_PPS_OUT(_PPS_RPB0R),		//	2  RB0		PGED1/AN2/C1IND/C2INB/C3IND/RPB0/RB0
	_PPS_OUT(_PPS_RPB1R),		//	3  RB1		PGEC1/AN3/C1INC/C2INA/RPB1/CTED12/RB1 
	_PPS_OUT(_PPS_RPB2R),		//	4  RB2		AN4/C1INB/C2IND/RPB2/SDA2/CTED13/RB2 	
	_PPS_OUT(_PPS_RPB3R),		//	5  RB3		AN5/C1INA/C2INC/RTCC/RPB3/SCL2/RB3
	_PPS_OUT(_PPS_RPA2R),		//	6  RA2		OSC1/CLKI/RPA2/RA2
	_PPS_OUT(_PPS_RPA3R),		//	7  RA3		OSC2/CLKO/RPA3/PMA0/RA3
	_PPS_OUT(_PPS_RPB5R),		//	8  RB4		SOSCI/RPB4/RB4
	_PPS_OUT(_PPS_RPA4R),		//	9  RA4		SOSCO/RPA4/T1CK/CN0/RA4
	_PPS_OUT(_PPS_RPB5R),		//	10 RB5		B5PGED3/PRB5/PMD7/RB5
	_PPS_OUT(_PPS_RPB6R),		//	11 RB6		PGB6EC3/RPB6/PMD6/RB6
	_PPS_OUT(_PPS_RPB7R),		//	12 RB7		RPB7/CTED3/PMD5/INT0/RB7
	_PPS_OUT(_PPS_RPB8R),		//	13 RB8		RPB8/SCL1/CTED10/PMD4/RB8
	_PPS_OUT(_PPS_RPB9R),		//	14 RB9		RPB9/SDA1/CTED4/PMD3/RB9
	_PPS_OUT(_PPS_RPB10R),		//	15 RB10		PGED2/RPB10/CTED11/PMD2/RB10
	_PPS_OUT(_PPS_RPB11R),		//	16 RB11		PGEC2/RPB11/PMD1/RB11
	NOT_PPS_PIN,				//	17 RB12		AN12/PMD0/RB12
	NOT_PPS_PIN,				//	18 RB13		AN11/RPB13/CTPLS/PMRD/RB13	
	_PPS_OUT(_PPS_RPB14R),		//	19 RB14		CVREF/AN10/C3INB/RPB14/SCK1/CTED5/PMWR/RB14
	_PPS_OUT(_PPS_RPB15R)		//	20 RB15		AN9/C3INA/RPB15/SCK2/CTED6/PMCS1/RB15
};

and the mapping for input looks like:

const uint8_t digital_pin_to_pps_in_PGM[] = {
	_PPS_IN(_PPS_RPA0R),		//	0  RA0		VREF+/CVREF+/AN0/C3INC/RPA0/CTED1/RA0
	_PPS_IN(_PPS_RPA1R),		//	1  RA1		VREF-/CVREF-/AN1/RPA1/CTED2/RA1
	_PPS_IN(_PPS_RPB0R),		//	2  RB0		PGED1/AN2/C1IND/C2INB/C3IND/RPB0/RB0
	_PPS_IN(_PPS_RPB1R),		//	3  RB1		PGEC1/AN3/C1INC/C2INA/RPB1/CTED12/RB1 
	_PPS_IN(_PPS_RPB2R),		//	4  RB2		AN4/C1INB/C2IND/RPB2/SDA2/CTED13/RB2 	
	_PPS_IN(_PPS_RPB3R),		//	5  RB3		AN5/C1INA/C2INC/RTCC/RPB3/SCL2/RB3
	_PPS_IN(_PPS_RPA2R),		//	6  RA2		OSC1/CLKI/RPA2/RA2
	_PPS_IN(_PPS_RPA3R),		//	7  RA3		OSC2/CLKO/RPA3/PMA0/RA3
	_PPS_IN(_PPS_RPB5R),		//	8  RB4		SOSCI/RPB4/RB4
	_PPS_IN(_PPS_RPA4R),		//	9  RA4		SOSCO/T1CK/CN0/RA4
	_PPS_IN(_PPS_RPB5R),		//	10 RB5		B5PGED3/PRB5/PMD7/RB5
	_PPS_IN(_PPS_RPB6R),		//	11 RB6		PGB6EC3/RPB6/PMD6/RB6
	_PPS_IN(_PPS_RPB7R),		//	12 RB7		RPB7/CTED3/PMD5/INT0/RB7
	_PPS_IN(_PPS_RPB8R),		//	13 RB8		RPB8/SCL1/CTED10/PMD4/RB8
	_PPS_IN(_PPS_RPB9R),		//	14 RB9		RPB9/SDA1/CTED4/PMD3/RB9
	_PPS_IN(_PPS_RPB10R),		//	15 RB10		PGED2/RPB10/CTED11/PMD2/RB10
	_PPS_IN(_PPS_RPB11R),		//	16 RB11		PGEC2/RPB11/PMD1/RB11
	NOT_PPS_PIN,	//	17 RB12		AN12/PMD0/RB12
	NOT_PPS_PIN,		//	18 RB13		AN11/RPB13/CTPLS/PMRD/RB13	
	_PPS_IN(_PPS_RPB14R),		//	19 RB14		CVREF/AN10/C3INB/RPB14/SCK1/CTED5/PMWR/RB14
	_PPS_IN(_PPS_RPB15R)		//	20 RB15		AN9/C3INA/RPB15/SCK2/CTED6/PMCS1/RB15
};

However, in digging into this, I see the following line in mapPps in wiring.c:

/* Check if the requested peripheral input can be mapped to
	** the requested pin.
	*/
	if ((ppsSetFromPin(pin) & ppsSetFromFunc(func)) == 0)
	{
		return false;
	}

Now, for some reason I'm not understanding yet, this fails. ppsSetFromPin would return 0 (

((3 >> 4) &0x000F)

) and ppsSetFromFunc would return 1 (

((0x101 >> 8) &0x000F)

), causing the conditional to fail.

What have I missed?

EmbeddedMan

Tue, 11 Mar 2014 12:53:19 +0000

I'm pretty sure you're running across a bug that I just fixed in the MPIDE core. The bug was that certain PPS related mapping macros had typecasts of only 8 bit ints, when they needed to return 16 bits.

If you want, you can try the latest MPIDE test build ([url]http://chipkit.s3.amazonaws.com/builds/mpide-0023-windows-20140307-test.zip[/url] for Windows) which has these problems fixed. See if that helps.

*Brian

GrahamM242

Tue, 11 Mar 2014 15:27:33 +0000

I wish it had been that simple! Sadly that didn't fix the issue, but I'll tell you what did - I discovered my own stupidity.

I'd mapped the elements in digital_pin_to_pps_in_PGM[] using the wrong names. I had used the following: _PPS_IN(_PPS_RPA0R) instead of using _PPS_IN(_PPS_RPA0)

That, of course, broke the carefully crafted PPS system, and stopped everything working. It's now fixed and seems to work as it should.

EmbeddedMan

Tue, 11 Mar 2014 18:44:09 +0000

Very glad to hear it!

*Brian

EmbeddedMan

Tue, 22 Apr 2014 12:18:43 +0000

hmm. No posts for many days. Just checking that the forum is still writable.

*Brian

majenko

Tue, 22 Apr 2014 17:50:40 +0000

hmm. No posts for many days. Just checking that the forum is still writable. *Brian

No, it isn't. You're just imagining this.

chipKIT is now so perfect nobody has any issues with it.

JohnL

Fri, 17 Jun 2016 11:16:13 +0000

Graham,

I've created the requisite Boards_Defs.h/Board_Dad.c files and modified the boards.txt file to include them.

If you are still active on the forum.

Would you mind sharing files ? I am relatively new to MPIDE and would like to get things going with MX150B Uart bootloader.

Would be much appreciated.