FT232RL and PIC24F not working right

[osmosis321]

I've got it connected properly, I'm sure, but something isn't configured right.

The PIC sends 0x00 - 0xFF out as a test pattern, but what I get from PuTTY is basically garbage.  There are repeating chars in it and it doesn't have any resemblance to the test pattern.

Anyone have any clue?  I've exhausted all my apparent options.  I've played with the eeprom settings, played with the VCP settings, attempted different UART settings on the PIC..  what am I missing here?

[armandas]

Do you have a scope to check the data on the TxD pin on the PIC? Also, 0x00 and 0xFF *are* garbage. Print something readable, such as 0x41 (letter 'A').

Obviously, timing settings, baud rate etc. could screw everything up.

[osmosis321]

Do you have a scope to check the data on the TxD pin on the PIC? Also, 0x00 and 0xFF *are* garbage. Print something readable, such as 0x41 (letter 'A').

Obviously, timing settings, baud rate etc. could screw everything up.

Yeah I'll have to scoot it over to the scope and see what's up with the TxD pin.  More on that later, I'm sure.

I disagree about the choice of print characters though.  When debugging a serial link such as this, where the problem could involve shifted bits, and the output must be viewed in hex to be meaningful, a test pattern of 0-255 provides much more useful information than limiting it to alphanumeric characters.

[osmosis321]

Here's where I'm at now:

I fiddled and fiddled and stumbled upon a BRG value range that works, and suddenly bytes were being broadcast properly to my terminal (PuTTY.)

I can't emphasize enough the need for fiddling when it comes to the BRG value, especially in light of the datasheet errata clarification document, which summarizes:

11. Module: UART
When the UART is in High-Speed mode, BRGH
(UxMODE<3>) is set; some optimal UxBRG
values can cause reception to fail.

After reading and re-reading the datasheet and errata for the UART (don't say RTFM.  I DID!) I've come to some conclusions for the PIC24F - FT232RL scenario:

1) It matters not how I configure the FT eeprom with FT_Prog.  Inverting or boosting signals will neither help nor hinder the transfer and should only be attempted as an absolute last resort.
2) BRGH doesn't matter, so long as the BRG calculation takes it into account.
3) Flow control mode (#RTS <--> #CTS) works just fine, and in fact simplex mode worked as far as I could tell.

This editor seems to have a glitch when a post reaches a certain size, so more in the next post.

[osmosis321]

With the FT232RL such a seemingly versatile IC, to the point where the designer can only screw up with the incorrect baud rate, why is it that I can send and not receive?

That is, data from the PIC through FT232RL to PC terminal comes through unscathed, but data does not make it through the other direction.  The TxD LED indicates the FT232RL received the byte, but the PIC never budges.

I hooked up the scope.  During the programming stage, I saw TxD flip flop a few times.  Pretty normal so far.  Yet beyond that, TxD never even twitched, despite the LED indicating reception.

I have a theory on what's going wrong, but I'd like to hear the thoughts of others before I reveal what it is.

[TopherTheME]

Did you modify the firmware in the FT232RL? Did you try doing an echo test? That have the Tx and Rx on the PIC probed, then send data to the PC from the PIC and then echo the exact same thing back. If all is correct, you should get the same thing on both channels of the oscilloscope. Otherwise, you don't know if its a PIC problem or a FT232RL problem.

I'm surprised you are having so much trouble. I'm currently using the same chip for a project to talk between a PIC32 and Excel on a PC and amazingly enough, its been very undifficult to get working.

[osmosis321]

Did you modify the firmware in the FT232RL?

No, I haven't gone there.  I know it's possible but I don't know where to find the firms or how to program them myself.  I'm assuming that shouldn't be necessary, especially in light of the fact that everything else works.

Did you try doing an echo test? That have the Tx and Rx on the PIC probed, then send data to the PC from the PIC and then echo the exact same thing back. If all is correct, you should get the same thing on both channels of the oscilloscope. Otherwise, you don't know if its a PIC problem or a FT232RL problem.

I believe it's an FT232RL problem.  Remember, the LED lights up showing the character entering the FT, but the TxD pin shows no activity, except for a few flip-flops at program time.

its been very undifficult to get working.

Oh I Imagine it is, normally.  I imagine this is one of the simplest problems since the advent of CMOS (hint hint.)

[Balaur]

Oh I Imagine it is, normally.  I imagine this is one of the simplest problems since the advent of CMOS (hint hint.)

OK, I'll bite:

- Problem with I/O configuration of the required PIC pins?
- You said that the flow control mechanism (I imagine a HW CTS/RTS since you mentioned those signals) works correctly. Yeah, but in both directions? Drop the flow control in a first step and try without it. Question: do you really dedicated 4 MCU pins just for the serial link?
- The TXDEN option was somehow deactivated?
- Just to get this out of the way, you should not need pull-ups or have some strange voltage level problems if that's what your hint was about

Well, keep us posted.

[osmosis321]

nono it's much simpler than that, I reckon.

I think I've destroyed the chip, likely with static discharge.