CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
[SOLVED!] PIC24/PCD Discrete IO Sanity Check

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

[SOLVED!] PIC24/PCD Discrete IO Sanity Check
PostPosted: Sat Sep 26, 2009 9:24 pm     Reply with quote
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

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 5:16 am     Reply with quote
Quote:
one bit toggled interferes with the other
How do you see the interferences?
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 11:57 am     Reply with quote
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

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 3:43 pm     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 3:48 pm     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 8:46 pm     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 9:41 pm     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Sep 27, 2009 9:57 pm     Reply with quote
And on another note:

I hooked up my ICD2 and get the same behavior.

Sad

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

View user's profile Send private message

PostPosted: Mon Sep 28, 2009 12:01 am     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Mon Sep 28, 2009 12:30 am     Reply with quote
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: 1615
Location: Central Illinois, USA

View user's profile Send private message

[SOLVED] PIC24/PCD Discrete IO Sanity Check
PostPosted: Sun Oct 11, 2009 4:31 pm     Reply with quote
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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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