 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
| [SOLVED!] PIC24/PCD Discrete IO Sanity Check |
 Posted: Sat Sep 26, 2009 9:24 pm |
 |
|
I need a sanity check for my Explorer16 w/PIC24FJ128GA010
I'm experiencing bit interference (or however you want to term it) using FAST_IO (part of testing the ENC28J60...
I'm seeing at my code runs (either stepping or adding delays) that one bit toggled interferes with the other in the following example:
Am I missing something stupid? I checked the docs on read/write operations and I believe I'm being burned by something else.
-Ben
| Code: |
//////// Program memory: 44030x24 Data RAM: 8192 Stack: 31
//////// I/O: 85 Analog Pins: 16
//////// Fuses: JTAG,NOJTAG,PROTECT,NOPROTECT,WRT,NOWRT,DEBUG,NODEBUG,ICSP1
//////// Fuses: ICSP2,WDT,NOWDT,WINDIS,NOWINDIS,WPRES128,WPRES32,WPOSTS1
//////// Fuses: WPOSTS2,WPOSTS3,WPOSTS4,WPOSTS5,WPOSTS6,WPOSTS7,WPOSTS8
//////// Fuses: WPOSTS9,WPOSTS10,WPOSTS11,WPOSTS12,WPOSTS13,WPOSTS14
//////// Fuses: WPOSTS15,WPOSTS16,IESO,NOIESO,FRC,FRC_PLL,PR,PR_PLL,SOSC
//////// Fuses: LPRC,FRC_PS,CKSFSM,NOCKSFSM,OSCIO,NOOSCIO,NOPR,HS,XT,EC
//////// Fuses: CKSNOFSM,COE
#include <24FJ128GA010.H>
#device ICD=true // I'm using an ICD3
#fuses HS
#fuses NOIESO // No 2-speed Start Up
#fuses NOJTAG // No JTAG
#fuses NOPROTECT // No Memory Protection
#fuses NOWDT // No WatchDog Timer
#fuses NODEBUG // Debug Mode.
#opt 9
#use delay(clock=32M, crystal=8M)
#define EEPROM_SELECT PIN_D12 //o
#define EEPROM_DI PIN_G8 //o
#define EEPROM_DO PIN_G7 //i
#define EEPROM_CLK PIN_G6 //o
#define EEPROM_SIZE 32767
#define PIN_ENC_MAC_CS PIN_D14 // PIC >>>> ENC
#define PIN_ENC_MAC_SI PIN_F8 // PIC >>>> ENC
#define PIN_ENC_MAC_SO PIN_F7 // PIC <<<< ENC
#define PIN_ENC_MAC_CLK PIN_F6 // PIC >>>> ENC
#use fast_io(b)
#use fast_io(d)
#use fast_io(e)
#use fast_io(f)
#use fast_io(g)
#use rs232(UART2, STREAM=USER, baud=115200, bits=8)
unsigned int const porta_settings = 0xffff;
unsigned int const portb_settings = 0xffff;
unsigned int const portc_settings = 0xffff;
unsigned int const portd_settings = 0xffff;
unsigned int const porte_settings = 0xffff;
unsigned int const portf_settings = 0xffff;
unsigned int const portg_settings = 0xffff;
void main (void) {
set_tris_a(porta_settings);
set_tris_b(portb_settings);
set_tris_c(portc_settings);
set_tris_d(portd_settings);
set_tris_e(porte_settings);
set_tris_f(portf_settings);
set_tris_g(portg_settings);
output_drive(EEPROM_SELECT);
output_drive(PIN_ENC_MAC_CS);
output_high (PIN_ENC_MAC_CS);
output_high (EEPROM_SELECT);
delay_ms(250);
fprintf(USER, "\r\n\n\nGPIO Tests\r\n");
while (true) {
output_low(PIN_ENC_MAC_CS);
// delay_us(10);
output_high(PIN_ENC_MAC_CS);
// delay_ms(1000);
output_low(EEPROM_SELECT);
// delay_us(10);
output_high(EEPROM_SELECT);
// delay_ms(1000);
}
}
|
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Last edited by bkamen on Sun Oct 11, 2009 7:11 pm; edited 1 time in total |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Sep 27, 2009 5:16 am |
|
|
| Quote: | | one bit toggled interferes with the other |
How do you see the interferences? |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sun Sep 27, 2009 11:57 am |
|
|
When I toggle one bit (say set) the other bit clears...
Then when I go to set the other bit, the first one clears.
The assembly shows me only manipulating one bit while the debug WATCH window (and my scope) both confirm that the other bit changes as well.
I know MCHP recommends a NOP delay on a write before read, but I'm not doing that. PCD changes the bits with bclr.b and bset.b to the right location and the right bit.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Sep 27, 2009 3:43 pm |
|
|
| I run your code on PIC24FJ128GA010 under MPLAB 8.36 with ICD2 and didn't see any irregular behaviour when switching the port pins. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sun Sep 27, 2009 3:48 pm |
|
|
Hmmmmm..
Are you using an Explorer16 board?
Did you double check with a scope?
I swear I'm not crazy...
(I'm using MPLAB 8.36, PCD 4.099, ICD3)
Let me get a scope shot online to show..
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sun Sep 27, 2009 8:46 pm |
|
|
Consider this code fragment where I just changed the #defines a little to match up with my scope's ~CS1 and ~CS2
| Code: | while (true) {
output_low(PIN_ENC_MAC_CS1);
delay_us(10);
output_high(PIN_ENC_MAC_CS1);
// delay_us(10);
// output_low(EEPROM_CS2);
// delay_us(10);
// output_high(EEPROM_CS2);
delay_ms(500); |
In the current form, I would expect (and get) a 10uS pulse (-width) on ~CS1.
If I uncomment the remaining code, I should get the same 10uS pulse with a 10uS delay followed by another 10uS pulse on ~CS2.
What I get looks like:
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sun Sep 27, 2009 9:41 pm |
|
|
As a sidenote,
MPLAB SIM produces exactly what I would expect the code to produce:
(CS1 is on the bottom)
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sun Sep 27, 2009 9:57 pm |
|
|
And on another note:
I hooked up my ICD2 and get the same behavior.
I changed the #defines to F8 and G8 (SDO1 and SDO2) while the SPI is not being used to see if the IO works as expected and it does. (granted they are different ports)
So I changed it to both pins toggling on either PORTF or PORTG, and it works.
Funky.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Sep 28, 2009 12:01 am |
|
|
I get regular pulses running your original code (with the timing changed according to your last example),
in ICD and non-debug mode. Assuming your code is identical, there seems to be a hardware problem in
your setup.
P.S.: Just to check the actual coding of the complete loop
| Code: | .................... while (true) {
.................... output_low(PIN_ENC_MAC_CS);
00282: BCLR.B 2D7.6
.................... delay_us(10);
00284: REPEAT #9E
00286: NOP
.................... output_high(PIN_ENC_MAC_CS);
00288: BSET.B 2D7.6
.................... delay_us(10);
0028A: REPEAT #9E
0028C: NOP
....................
.................... output_low(EEPROM_SELECT);
0028E: BCLR.B 2D7.4
.................... delay_us(10);
00290: REPEAT #9E
00292: NOP
.................... output_high(EEPROM_SELECT);
00294: BSET.B 2D7.4
.................... delay_ms(500);
00296: MOV #1F4,W0
00298: CALL 21E
.................... }
0029C: GOTO 282 |
|
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Mon Sep 28, 2009 12:30 am |
|
|
I already have a trouble ticket in with MicroChip.
It's years old. (although new in the box) -- I got the PIM with my Explorer16 from a seminar I went to in [spam]. <-- (Chi-town == spam!?!?)
I think I have a bad PIC.
-Ben
p.s. for fun, I tried a write to the port pin, then an LED pin, then back to a port pin. That doesn't "work" either. Pretty wild.
Thanks for your validation, FvM.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
| [SOLVED] PIC24/PCD Discrete IO Sanity Check |
| Posted: Sun Oct 11, 2009 4:31 pm |
|
|
Turned out to be a bad PIC24FJ128GA010.
Microchip sent me a (free) replacement and it works as expected.
I'd post more screenshots, but they would be redundant to the simulated trace already posted.
Now I can back to the PCD TCP/IP "port".
:D
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
