PIC18 PORTE.F0 - Page 1
Forum section: electronics / general

author: Pack34
author_rank: Frequent Contributor
timestamp: October 24, 2014, 12:10:41 pm
content: I've been having some consistent issues working with RE0 on both the PIC18F6622 and the PIC18F4680.They both have the same peripherals assigned, straight digital I/O, read control for parallel slaves, and the 4680 also doubles as an analog.I typically throw INTCON.GIE along with the timer and USART enables. Could this be an issue causing the !RD of the PSP to be switched to an input? Or what?E0 just has always been fickle and I have no idea why...

author: Pack34
author_rank: Frequent Contributor
timestamp: October 24, 2014, 02:03:04 pm
content: It's probably an issue elsewhere, since I seem to be able throttle the pin just fine. It's probably just happenstance but my problems always seem to linger around that pin.

author: dannyf
author_rank: Super Contributor
timestamp: October 24, 2014, 02:39:29 pm
content: : probably an issue elsewhere, :like in your code?the lack of response reflects your lack of information.help others help you.

author: dannyf
author_rank: Super Contributor
timestamp: October 25, 2014, 12:09:20 pm
content: To get you going, download this into your 6622 and see what happens on PORTE.Code::04000000C1EF7FF0DD:10FF82000001D3EF7FF0E8CF01F001060128D8B4D9:10FF92001200FBD70F0EC16E070EB46ED38CD38A3C:10FFA200D388070CCBEC7FF0966AFF0E841A056AA1:10FFB200640E046EDEEC7FF0F8D705D0036AA00E63:10FFC200026EEDEC7FF00406D8A005060428D8B432:10FFD2000528D8B41200F2D70250C4EC7FF00350C7:10FFE200026E036A03D0FF0EC4EC7FF00206D8A0B3:0EFFF20003060228D8B40328D8B41200F4D7AE:020000040030CA:0E000000FF08181EFF0180FFFFC0FFE0FF4059:00000001FF

author: Pack34
author_rank: Frequent Contributor
timestamp: October 26, 2014, 11:09:32 pm
content: I apologize for the incoherent post. It was made before my morning coffee...Throwing in a while-true and toggling the state of the port every 100ms produces the appropriate waveform on the scope. So I'm leaning towards the problem being elsewhere... I'm working with an ENC28J60 and the MikroC IDE comes with a nice library for it. Unfortunately, because it's a neatened-up library so much is hidden so it's difficult to troubleshoot the exact cause of the issue.The same code works on two other designs, but not this new one. The only difference is that I've moved the chip select and reset lines to E0 and E1 to make the layout flow a bit better. (E0 has always been wonky in my career so far...) I've yet to wire-up a breakout of the chip to a dev board using the exact pinout, but I'm thinking it's a hardware problem with the board itself. The SPI clock and MOSI lines are throwing but the transceiver just isn't talking back.I am a bit concerned though that I'm not seeing the chip select lines being thrown but I'll verify the working behavior on the dev board in one of the upcoming days. It's one of the many projects on my plate so I'm highly unlikely to be able to find time to work on it multiple days in a row, or for a full day for that matter. My boss tends to re-task every couple hours...I'll report back if I find out anything interesting.

author: atferrari
author_rank: Frequent Contributor
timestamp: October 27, 2014, 10:33:11 am
content: Check their site for erratas. Believe me; it is worth the time spent.

author: Pack34
author_rank: Frequent Contributor
timestamp: October 27, 2014, 10:35:10 pm
content: Can the continuity setting on a multimeter be enough to damage a 3v3 chip? I was having some issues soldering together the prototypes (tssop) and I double checked my connections using a Fluke 77. I checked the voltage put out by the setting with my Fluke 187. Surprisingly it was up at 7V.Testing a couple meters in the lab on both resistance and continuity, it looks like I should be using resistance instead. Although the continuity setting on one of the unbranded ones is about 1.2V.