 |
 |
View previous topic :: View next topic |
Author |
Message |
maxrate
Joined: 01 Jan 2007 Posts: 43 Location: Mississauga, Ontario, Canada
|
i2c 18F46K22 slave - MCLR makes project work |
Posted: Sat Jul 26, 2025 6:32 pm |
|
|
Hi all - I have a simple two 18F46K22 project. All for testing; the master is sending out 3 bytes of data every 3 seconds. The slave shows the data on an RS232 port.
When I power up the slave, I get my RS232 message saying 'slave device start'... I then expect to see the three inbound bytes of data echoed to the RS232 port, but I get nothing.
Nothing until I short the MCLR line to ground on the slave PIC.
This is a custom PCB with (2) 18F46K22's on board. The C3/C4 lines of both MCU's are connected to each other with 4.7k pull ups.
When I hook up the scope, the CLK and DATA lines are 'high', then after the 'slave device start' message (approx 1-2 seconds) the CLK line goes low and stays low. When I GND out MCLR on the slave, the CLK line gets pulled high, then when I remove GND signal from MCLR, the program executes the way you would expect it to.
From a cold start, I get the RS232 'slave device start' message, but not I2C signal (CLK signal pulled low). When I GND MCLR, CLK immediately goes HIGH, when I relieve MCLR from GND, program works.
Baffled. Anything I can do with FUSES/switches? Pretty happy with the PCB overall. Only two rast nest wires from two lines I forgot to route + MCLR was left floating, but I've soldered in a 10K resistor from 5V to MCLR.
Compiler 5.117
MAIN.H
Code: | #include <18F46K22.h>
#device ADC=10
#FUSES NOWDT //No Watch Dog Timer
#ZERO_RAM
//#device ICD=TRUE
#use delay(clock=64MHz,crystal=16MHz)
#use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=PORT2)
#use rs232(baud=115200,parity=N,xmit=PIN_D6,rcv=PIN_D7,bits=8,stream=PORT1)
#use i2c(Slave,Slow,sda=PIN_C4,scl=PIN_C3,address=0x14,force_hw)
#define LED PIN_D1
#define DELAY 100
char c;
int state;
char sspbuff[4]; // inbound circular buffer for i2c bus
int sspnext = 0; // inbound i2c position
int sspProcess = 0; // processing flag for i2c contents of sspbuff
|
MAIN.C
Code: |
#include <main.h>
#INT_RDA
void RDA_isr(void)
{
}
#INT_SSP
void SSP_isr(void)
{
state = i2c_isr_state(); // capture i2c state
c = i2c_read(); // capture i2c data
if (sspnext==3) { // reset the circular buffer if too long
sspnext=0;
}
if (state==0x00) { // reset the position address to 0 when recieved data is actually just the slave address ( i2c trigger)
sspnext = 0;
return; // exit sub
}
if (state<0x80) { // data is present, commit to circular buffer
sspbuff[sspnext] = c;
sspnext++;
if(sspnext==3) {
sspProcess=1;
}
}
}
void main()
{
enable_interrupts(INT_SSP);
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
delay_ms(10);
fprintf(PORT1, "Slave device start.\r\n");
delay_ms(10);
while(TRUE)
{
//Example blinking LED program
output_low(LED);
delay_ms(DELAY);
output_high(LED);
delay_ms(DELAY);
if (sspProcess==1) {
fprintf(PORT1, "->%X %X %X ", sspbuff[0], sspbuff[1], sspbuff[2]);
sspProcess=0;
};
//TODO: User Code
}
} |
|
|
 |
maxrate
Joined: 01 Jan 2007 Posts: 43 Location: Mississauga, Ontario, Canada
|
|
Posted: Sat Jul 26, 2025 7:38 pm |
|
|
Update: It has something to do with Code: | #use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=PORT2) |
When I comment this out, the CLK line of the i2c bus on C3 does not get pulled down after a few seconds and the program operates normally. Odd how GNDing MCLR for a moment resolves this.
Problem not solved as I need C6/C7 UART for my project. I hope this doesn't interfere. Perhaps there is another handshake pin being asserted or the ISR for RDA/RDA2 is triggering and not being cleared. Not certain. Will investigate further |
|
 |
maxrate
Joined: 01 Jan 2007 Posts: 43 Location: Mississauga, Ontario, Canada
|
|
Posted: Sat Jul 26, 2025 7:45 pm |
|
|
SOLVED - Okay, real simple error. RDA was receiving characters from a peripheral I didn't realize was attached. The peripheral boots up when I switch the power on to the board, characters are generated and put in the buffer, but I wasn't clearing them. I believe this has been resolved. Been at this for hours - not sure why I tend to figure things (relatively) shortly after I post.
Thanks for reading and giving consideration to the challenge. I'm still not 100% convinced this has resolved it - more testing tomorrow. |
|
 |
asmallri
Joined: 12 Aug 2004 Posts: 1655 Location: Perth, Australia
|
|
Posted: Sat Jul 26, 2025 11:03 pm |
|
|
maxrate wrote: | SOLVED - Okay, real simple error. RDA was receiving characters from a peripheral I didn't realize was attached. The peripheral boots up when I switch the power on to the board, characters are generated and put in the buffer, but I wasn't clearing them. I believe this has been resolved. Been at this for hours - not sure why I tend to figure things (relatively) shortly after I post.
Thanks for reading and giving consideration to the challenge. I'm still not 100% convinced this has resolved it - more testing tomorrow. |
You are missing the errors option from the use rs232 lines. This would explain your symptoms. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
 |
maxrate
Joined: 01 Jan 2007 Posts: 43 Location: Mississauga, Ontario, Canada
|
|
Posted: Sun Jul 27, 2025 6:20 am |
|
|
I concur. Thank you for that. I'm still trying to determine why the RS232 port would affect the HW I2C port, but I'm sure it's all tied together with the hardware buffer. Deep dive on the datasheet is needed here. First time I've mixed RS232 and I2C on the same PIC project. |
|
 |
temtronic
Joined: 01 Jul 2010 Posts: 9568 Location: Greensville,Ontario
|
|
Posted: Sun Jul 27, 2025 9:09 am |
|
|
hmm, maybe ( please don't shoot me....) , since you have the RDA interrupt enabled and nothing IN the 'handler', the PIC decides to 'hang' ???
it's toooo hot here to cut code... |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 19928
|
|
Posted: Sun Jul 27, 2025 9:46 am |
|
|
Spot on.
If any character is received, the INT_RDA can never exit, since the
character is not read, the interrupt cannot be cleared. Result hang....  |
|
 |
maxrate
Joined: 01 Jan 2007 Posts: 43 Location: Mississauga, Ontario, Canada
|
|
Posted: Sun Jul 27, 2025 9:51 am |
|
|
temtronic & Ttelmah - as always, I appreciate your comments. I agree 100% this is the issue - I've since cleaned things up significantly. I was hyper focused on why the I2C CLK line was going low, not realizing the chip was hung up. What really confused me is I didn't realize I had a device attached to the UART feeding the PIC's UART characters (I thought the port was not being used at the time). All adds up. Mystery solved! |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|