PIC24FJ128GB202 COM port

[starfire151]

I've created a minimal testbed using a PIC24FJ128GB202 to check multiple com port activity. I have a heartbeat LED connected to pin A4 which is toggled every second.

In my first version, I simply echo the uppercase character seen on COM1 (TXD on pin 3, RXD on pin B2).

I initialized everything then enabled the interrupts for TIMER1 and RDA.

1. I'm not seeing my heartbeat pin toggle at all. This is the same code for initializing and starting the timer that I have working correctly with a PIC24FV32KA301.

2. I'm seeing a 3-character delay before seeing any characters echoed to COM1. The first character seems to be corrupt (invalid character) and then the correct data is seen. In explaining, if I enter 1 2 3 4 5 6 7 8, I see a y character with an umlaut (..) above it then 1 2 3 4 5. When I first power up, I have a message printed to the com port and it prints out completely and correctly.

My simple code is as follows:

[starfire151]

Sorry, I forgot to include the specific...

PCWHD V5.064
Windows 10 desktop

Thanks, again.

[PCM programmer]

For the initial garbage character, try the following:
1. Put a 100 ms delay at the very beginning of main().
If that doesn't work, then:
2. Add a 10K pullup resistor on the Rx pin.

[starfire151]

I tried the 100ms delay at the beginning of main(). There didn't appear to be any change. I also tried the 10K pullup to 3.3VDC on the receive pin but there was no change there, either.

I also tried a 10ms delay prior to the fputc() call. No help.

It appears the outgoing characters just sit in the output buffer until it fills and then the characters are sent out (FIFO). I'm not sure how to clear out the first character in the buffer.

Any idea on the TIMER1 problem?

Thanks for looking at this.

[starfire151]

I found the problem with the heartbeat pin. I changed the heartbeat to pin A3 and it works fine. There must be some restriction on output usage for pin A4?

[temtronic]

hmm.. are you sure it's a PIC problem and NOT a Windows10 problem ?

Maybe have an LED toggle for every character sent to PC ?
This would confirm it was sent and the PC is 'slow' to repond.

Jay

[jeremiah]

[starfire151]

jeremiah:

I have the #fuses oscio called out in the beginning of the program. I didn't see a specific fuse associated with the secondary oscillator for io other than sosc, which I assumed was setting the sosc as an oscillator and not IO.

temtronic:

I don't think this is a Windows problem. The same development system is used for code for PIC24FV32KA301 and PIC24EP256GP202 processors with no problems with the com port interface.

[PCM programmer]

Look for the SOSC_DIG fuse. That sets it for normal i/o.

[starfire151]

I tried the adding the lines:

#fuses SOSC_DIG // secondary oscillator pins as IO (for pin A4 output)
#define HEARTBEAT PIN_A4 // 1-second heartbeat toggle

The output line A4 is still not toggling. When I moved it back to A3, it toggles OK.

I still have the problem of the serial output data being buffered and the first character being corrupted, also. This is a more serious issue, since I intended to use this chip with the multiple simultaneous serial ports. I wanted to eventually have hardware serial interrupts associated with COM1 (TX on pin B3, RX on pin B2), COM2 (unused TX on pin B11, RX on pin B10), and COM3 (unused TX on pin A1, RX on pin A0). I wanted to echo the characters from either COM2 or COM3 onto COM1 in a passive monitor mode.

[starfire151]

some additional information...

I connected a logic analyzer (with an integrated serial port interpreter) to the transmit line and looked for the serial data sent when a character was input. The logic analyzer triggered immediately when I entered the "1" key but it showed an output of 0x00. I entered the "2" key and it showed 0x00 on the output. I entered "3" and it showed 0xff on the output (the y with an umlaut), I entered "4" and it showed "1" on the output. I entered "5" and it showed "2". Every entry was delayed by 3 bytes...

[gaugeguy]

There is a 4 level receive buffer and a 4 level transmit buffer. You are having a problem with one of them. Make sure both are empty before you begin.

[starfire151]

I tried to find a way to check the output buffer status...

I added the line I = tx_buffer_bytes(COM1); before the line for the fputc(s1Char, COM1); but I get a compiler error:

Error 112 "test1.c" Line 78(1,1): Function used but not defined: ...tx_buffer_bytes 667 SCR=1208

How would I check for how many characters are in the output buffer? Better yet, how can I flush the buffer prior to sending a character and ensure any new characters go out immediately?

[newguy]

Divide and conquer. Try to isolate where the problem may lie.
- I see no problem with your RDA interrupt BUT to ensure that things are doing what you intend, in your main loop, in the if (S1Flag) {}, add output_toggle(HEARTBEAT) [and disable the heartbeat in your ClockISR().]

Then test by typing characters on your laptop and confirm that each character corresponds to the heartbeat LED toggling state. If it works as expected, reset the PIC and repeat several times to confirm that it wasn't a fluke and that it does what it's supposed to do every time the PIC is reset. If all this is confirmed, character reception can be ruled out as a problem

If it doesn't, I have a suspicion that your PIC may have an issue with the generation of the RDA interrupt and that there's an issue with the generation of that interrupt until the buffer fills completely. There may be a listing in that processor's errata along these lines.

Assuming the RDA functions as it should and you can confirm that the processor sees each character as it arrives (via the heartbeat toggling every time you send a character), your attention must then turn to the transmission of characters. The best way to confirm this is to simply place a character to transmit in the UART's output buffer (register) directly, and then trigger the transmission manually. Here you need to read the datasheet. For some of the 16 bit processors, the data sheet is very sparse but there will be a device family spec (very detailed). They/it will list exactly how to manually send a character via the UART. You should implement this to confirm that the CCS code doesn't have a bug. Again, there may be an errata that relates to the problem you're seeing.

[starfire151]

According to the errata for this chip, it states the UART1 and UART2 modules may assert the receive interrupt flag early.

I changed the code to not use interrupts at all. I just look for a kbhit() and do a fgetc(COM1) if seen and echo it to the COM1 port. It works. I do still get the y with an umlaut character (0xff) first, though.

I do get the first signon message (fprintf("PIC24FJ128GB202 Testbed\r\n");) three times when it resets, also, after programming. A reset after that has the 0xff character first then one signon message.

With the defective hardware receive interrupt of this part, and no workaround listed, it appears this part will be unsuitable for my eventual application.

Does anyone have an idea of what would a good PIC24 part to use with 4 operational hardware receive interrupts?