 |
 |
| View previous topic :: View next topic |
| Author |
Message |
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| DEBUG fuse breaks software UART |
 Posted: Thu Jun 03, 2004 10:06 am |
 |
|
I'm working with a PIC16F88, and I'm communicating with a GPS peripheral on a software UART: pins 17/RA0 (RX) & 18/RA1 (TX). I'm running the debug stream on pin A7. I've found that when the DEBUG fuse is set, I get garbage characters from the GPS UART. When the DEBUG fuse is not set, the GPS UART works fine. Not only that, but the DEBUG fuse seems to have no effect at all on my ability to debug and print to the debug monitor.
I'm trying to understand what the DEBUG fuse actually does. There seem to be other posts here describing DEBUG confusion.
--
Jeff S. |
|
 |
Ttelmah
Guest
|
| Re: DEBUG fuse breaks software UART |
| Posted: Thu Jun 03, 2004 2:40 pm |
|
|
| object01 wrote: | I'm working with a PIC16F88, and I'm communicating with a GPS peripheral on a software UART: pins 17/RA0 (RX) & 18/RA1 (TX). I'm running the debug stream on pin A7. I've found that when the DEBUG fuse is set, I get garbage characters from the GPS UART. When the DEBUG fuse is not set, the GPS UART works fine. Not only that, but the DEBUG fuse seems to have no effect at all on my ability to debug and print to the debug monitor.
I'm trying to understand what the DEBUG fuse actually does. There seem to be other posts here describing DEBUG confusion.
--
Jeff S. |
The debug fuse, enables the ability to use the chip for in-circuit debugging, using pins RB6, and RB7. When set, a section of 'handler' code will be added at the top of memory (this could well stop a program that is big, working). Also once enabled, on most PICs, the pins used for this ability, must be connected to circuitry, that ensures they don't float, or the chip won't run. It sounds as though you are confusing this ability, with the ability to deliver status messages using another serial stream.
Best Wishes |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
|
| Posted: Thu Jun 03, 2004 2:44 pm |
|
|
I think that's what I mean by debugging. We have an ICD-U40 wired to pins RB6, RB7, and all other pins necessary for in-circuit debugging. I can debug the firmware in PCW by enabling the debugging and stepping through the code, and I can print to the debug monitor, which we have running on pin RA7.
I can do all this without the DEBUG fuse being set. That's what I don't understand. Setting the DEBUG fuse enables no new functionality, and prevents the aforementioned software UART from working.
--
Jeff S. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Jun 04, 2004 1:58 am |
|
|
| object01 wrote: | I think that's what I mean by debugging. We have an ICD-U40 wired to pins RB6, RB7, and all other pins necessary for in-circuit debugging. I can debug the firmware in PCW by enabling the debugging and stepping through the code, and I can print to the debug monitor, which we have running on pin RA7.
I can do all this without the DEBUG fuse being set. That's what I don't understand. Setting the DEBUG fuse enables no new functionality, and prevents the aforementioned software UART from working.
--
Jeff S. |
OK. In this case, I'd suggest that if programming using the ICD-U40, is overriding the fuse, and setting it itself, and possibly gets confused when it is set in the software. Have you looked at the config bits in the hex file, and checked that the fuse setting does correctly toggle the bit?. It normally does. What I woul suspect is happening, is that when you set the fuse, the fuse is correctly set, but the upper memory handler is not loaded, which will then prevent the processor running.
Best Wishes |
|
|
|
|
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
