FT232RL and PIC24F not working right - Page 1
Forum section: electronics / projects

author: osmosis321
author_rank: Regular Contributor
timestamp: December 05, 2010, 07:03:25 pm
content: 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?

author: armandas
author_rank: Frequent Contributor
timestamp: December 05, 2010, 07:26:08 pm
content: 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.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 05, 2010, 07:45:15 pm
content: Quote from: armandas on December 05, 2010, 07:26:08 pmYeah 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.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 09, 2010, 08:49:27 pm
content: 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: UARTWhen the UART is in High-Speed mode, BRGH(UxMODE<3>) is set; some optimal UxBRGvalues 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.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 09, 2010, 09:39:46 pm
content: 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.

author: TopherTheME
author_rank: Regular Contributor
timestamp: December 09, 2010, 11:20:08 pm
content: 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.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 10, 2010, 12:06:41 am
content: Quote from: TopherTheME on December 09, 2010, 11:20:08 pmNo, 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.Quote from: TopherTheME on December 09, 2010, 11:20:08 pmI 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.Quote from: TopherTheME on December 09, 2010, 11:20:08 pmOh I Imagine it is, normally. I imagine this is one of the simplest problems since the advent of CMOS (hint hint.)

author: Balaur
author_rank: Unknown
timestamp: December 10, 2010, 12:35:03 am
content: Quote from: osmosis321 on December 10, 2010, 12:06:41 amOK, 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 aboutWell, keep us posted.

author: osmosis321
author_rank: Regular Contributor
timestamp: December 10, 2010, 08:12:23 pm
content: nono it's much simpler than that, I reckon.I think I've destroyed the chip, likely with static discharge.