I/O config for PIC24F series - Page 1
Forum section: electronics / projects

author: osmosis321
author_rank: Regular Contributor
timestamp: December 28, 2010, 11:25:12 pm
content: Who here would like to earn my eternal gratitude by giving me the lowdown on setting up the PIC24F peripheral multiplexing?I'm trying to use I2C1 and UART1, and in both cases the outputs aren't working, I believe it's because I'm not setting up PPS properly or not configuring the TRIS bits properly, or maybe the peripheral is being overridden by a higher priority peripheral?It's all so confusing, and I'm all so desperate to find the answer.

author: migsantiago
author_rank: Frequent Contributor
timestamp: December 28, 2010, 11:57:49 pm
content: I can help.Show your current code, the PIC24 you're using, the compiler you're using, the module configurations you are looking for... and then... I might help.

author: Neb
author_rank: Newbie
timestamp: December 29, 2010, 12:27:47 am
content: I've used those PICs a lot, so i'll see if i can help.I think configuring the peripheral overwrites the TRIS setting, but i usually set the TRIS to the direction of the pin anyway (eg set UART Tx to output).To configure the UART Tx, you need to find the peripheral function number (U1TX is function 3) and assign it to a pin:RPOR2bits.RP4R = 3; // Make Pin RP4 U1TXTo configure the UART Rx, the syntax is reversed, so you assign function U1RX to pin RP5. Note, the register name (RPINR18) means register 18, not pin 18.RPINR18bits.U1RXR = 5; // Make Pin RP5 U1RXAlso, the PIC24FJ64GA... I2C1 has a brutal errata (check your chip's errata document) where it will not initialize unless you use another pin to pull SDA low first. But I2C2 should work properly.I found some decent I2C driver source code on the microchip website, but you will likely have to go through it to fix some of their bugs (iirc one of their control flags was backwards and caused a lockup) and configure it properly.

author: johnmx
author_rank: Frequent Contributor
timestamp: December 29, 2010, 12:45:20 am
content: I2C module is not currently included in the peripheral pin select feature.

author: Mechatrommer
author_rank: Super Contributor
timestamp: December 29, 2010, 01:18:15 am
content: what pic24f? maybe i will have a look at the documentation if i have a time or when this thread is rebumped.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 29, 2010, 08:56:22 am
content: OK let's start here. I had this working fine with I2C2, once I'd implemented the hardware and software fix for the 24F bug. Then when I switched to I2C1, it stopped working. Note: RA4 connects to SDA.void I2C_open(UINT brg){DisableIntMI2C1;CloseI2C1();OpenI2C1(I2C_ON|I2C_7BIT_ADD|I2C_IDLE_STOP|I2C_SLW_DIS, brg);// ----- Fix the 24F I2C bugTRISAbits.TRISA4 = 0; //RA4 = output (SDA pin)PORTAbits.RA4 = 0; //RA4 = LOWUINT counter;for(counter=0;counter<1000;counter++)Nop(); // Wait a bit to make sure (150ns max)TRISAbits.TRISA4 = 1; //RA4 = input (pulled high)Nop();I2C_start();Nop();I2C_stop();}I scoped it and I can see the bug fix taking place, but beyond that there's no activity on SDA. I strongly suspect that the JTAG peripheral is overriding I2C1 (this would also explain the UART problem). However, I've got JTAG turned off in the config bits.Any way I can at least test my theory? How can I rule out JTAG override? Just because it should be off doesn't mean it is.

author: migsantiago
author_rank: Frequent Contributor
timestamp: December 29, 2010, 01:50:59 pm
content: You are still NOT mentioning what PIC24 you are using.

author: Mechatrommer
author_rank: Super Contributor
timestamp: December 29, 2010, 02:02:22 pm
content: he mentioned in post topic "MPLAB 8.56 source for PIC24FJ16GA002" weird namedocumentationshere

author: Neb
author_rank: Newbie
timestamp: December 29, 2010, 03:34:16 pm
content: You need to enable the device while holding the pin low. Here's the code i used and it has worked for me.TRISBbits.TRISB12 = 0; // configure RB12 as output connected to SDA1LATBbits.LATB12 = 0; // pull RB9 low with RB12Nop();I2C1CON = 0x9200; // enable I2C1Nop();Nop();TRISBbits.TRISB12 = 1; // configure RB12 as input

author: osmosis321
author_rank: Regular Contributor
timestamp: December 29, 2010, 06:33:46 pm
content: Quote from: Neb on December 29, 2010, 03:34:16 pmMy fix works fine and so does yours. I'll probably use yours because it's smaller. It actually may have been working at that point but I just wasn't seeing it on the scope. It's working now!Thanks so much for the assist. Up next, the UART1 problem.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 29, 2010, 09:32:42 pm
content: Quote from: osmosis321 on December 29, 2010, 06:33:46 pm.. which has mysteriously disappeared. Now suddenly for no apparent reason, everything works fine?What is it with this Microchip stuff.. it works, it doesn't work, hardly any rhyme or reason to it. I gotta switch to atmel or something.

author: Mechatrommer
author_rank: Super Contributor
timestamp: December 30, 2010, 03:58:35 am
content: Quote from: osmosis321 on December 29, 2010, 09:32:42 pmatmel got similar problem... now you see it, now you dont. in the market place.

author: osmosis321
author_rank: Regular Contributor
timestamp: January 01, 2011, 08:22:03 pm
content: There's one last thing I need to get sorted out, and this one's wacky. Well ok, they're all wacky.Trying to share a few variables between mainline code and ISR. As is often the case, it USED TO work, but when I started trying to fix other things I ended up breaking it somehow.The behaviour I'm seeing now suggests that the memory isn't being accessed the way I expect. If I break in the ISR, the first 3 variables will show up as "Reserved Memory" and the 4th will show as a value, but it's the wrong value. Changes to the variables will cause unpredictable results, and the program resets shortly thereafter. Like the variable locations are being mapped to the stack frame or something.volatile BOOL input_flag=FALSE;volatile BOOL timer_flag=FALSE;volatile char input_data=0;volatile char timer_counter=0;void __attribute__((interrupt,no_auto_psv))_T1Interrupt(void){timer_flag = TRUE;timer_counter++;if(timer_counter > 3)timer_counter = 0;T1_Clear_Intr_Status_Bit;}void __attribute__((interrupt,no_auto_psv))_U1RXInterrupt(void){input_flag = TRUE;input_data = getcUART1();U1RX_Clear_Intr_Status_Bit;}

author: Unknown
author_rank: Unknown
timestamp: January 02, 2011, 12:16:35 am
content: Quote from: shafri on December 30, 2010, 03:58:35 amI have also felt this way with the triple comparator module on a PIC24FJ64GB108. Seemed like a bug in the MPLAB debugger coming and going. The most annoying is that some important fields in the datasheets are 'TBD' since 2006...

author: osmosis321
author_rank: Regular Contributor
timestamp: January 02, 2011, 05:07:04 am
content: hmm my 'spidey sense' is tingling with this one. I'm seeing... a problem.. elsewhere in my code.. corrupting the stack frame or something similar.

author: osmosis321
author_rank: Regular Contributor
timestamp: January 02, 2011, 02:04:49 pm
content: HA HAAAAAA!I suspect all the problems I've been having with this lately were due to the build configuration being set to release when I was trying to debug.