Has anyone actually used a PIC24?
I am finding so many problems...

One is:
There is NO MACRO to define the EMUC1,2,3 choice.
The documentation shows the actual config register to be "reserved".
(And all bits should be programmed as ones...) Obviously wrong.
The only way to set this configuration register is via MPLAB.
(I need to have it in my code!)

I have yet to get the ICD2 to debug my target board.
(Yes, the clock, and power are right.)
MICROCHIP suggested (rightly so) that the major reason is not selecting the
right EMUC and EMUD.  (I'm using EMUC2 and EMUD2.)
But no joy!

MPLAB:
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to target
Target Device PIC24HJ256GP206 found, revision = Rev 0x3000
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Programming Target...
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0xFFF)
Verifying...
...Program Memory
...Verify Succeeded
...Loading DebugExecutive
...Programming DebugExecutive
...Debug Executive
...Programming Debug Vector
...Debug Vector
...Programming Configuration Bits
.. Config Memory
Verifying configuration memory...
Connecting to debug executive
ICD0083: Debug:  Unable to enter debug mode.  Please double click this
message for more information.
MPLAB ICD 2 Ready

So, anyone been successful in using a PIC 24 in a design?
(Not their demo board!)

Tom

  *
  |  __O    Thomas C. Sefranek  WA1RHP@ARRL.NET
  |_-\<,_   Amateur Radio Operator: WA1RHP
  (*)/ (*)  Bicycle mobile on 145.41MHz PL74.4
 
ARRL Instructor, Technical Specialist, VE Contact.
http://hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Harold Hallikainen
Sent: Thursday, August 17, 2006 10:35 AM
To: piclist@mit.edu
Subject: [PIC] 18F6720 resetting itself

After producing several thousand systems, we're now finding that an
18F6720 based system is resetting itself on occasion for no apparent
reason. I've added the C18 code below to try to determine the reason for
the resets:

  WriteLogRecord(1,(RCON & 0x1f) | (STKPTR & 0xc0));	// log the power up
including the lsbs of the RCON register
 
// and the msbs of the stack pointer to log reason for reset
  #if 1									//
include reason for reset
       PutRomString("\r\nSystem reset by \0");
       if((RCON & 0x01)==0) PutRomString("brownout, \0");
       if((RCON & 0x02)==0) PutRomString("power up, \0");
       if((RCON & 0x04)==0) PutRomString("sleep, \0");
       if((RCON & 0x08)==0) PutRomString("watchdog timeout, \0");
       if((RCON & 0x10)==0) PutRomString("reset instruction, \0");
       if((STKPTR & 0x40)==0x40) PutRomString("stack underflow, \0");
       if((STKPTR & 0x80)==0x80) PutRomString("stack overflow, \0");
  #endif
  RCON|=0x1f;				// set all the reset detect
registers


I'm getting "System reset by" messages with nothing following, which seems
to indicate that none of the bits in the RCON register were cleared by the
reset, nor were the stack overflow or underflow bits set. This seems to
indicate it was a reset caused by the MCLR input. However, I have a scope
on the MCLR pin set to single sweep should the voltage go below 3.96V.
MCLR is supposed to have a low threshhold of 0.2Vcc and Vcc is 5V, so MCLR
should drop to 1V before it triggers a reset.

So, watching the RCON register indicates I'm getting an MCLR reset, but
watching the MCLR pin does not show a reset there.

This problem comes and goes. The system ran for several hours yesterday,
but reset several times overnight.

Ideas?

THANKS!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist