1

I am running an AtMega328P-PU at 3v3, 8MHz with external crystal successfully. I am able to burn the bootloader using ISP and flash the chip using FTDI and the clock seems right.

The mega is connected to a RFM69HCW, which uses the SPI interface and thus occupies the SCK, MISO, MOSI and SS along with int0 for RFM DIO0 and PD4 for RFM reset.

I am facing a problem where the FTDI interface does not work most of the time when the RFM is connected to the mega. There does not seem to be a pattern to when it works and when it does not, so I guess it might be something with timing (I do not have a scope, so I cannot verify this).

When the FTDI interface does not work (I cannot establish a serial connection - either using a monitor or uploading a program) the TX LED (red) on the USB-2-FTDI board is very dimly lit. I am using a Sparkfun FTDI Basic with the voltage jumper cut and soldered to 3v3. This board has auto-reset, no no need to reset the mega manually during programming (doing so does not change anything).

The FTDI interface works perfectly and reliably if I disconnect the RFM from the mega, so I suppose that it has something to do with this.

I have attached a schematic of my setup (it contains a few more components than my setup, so please disregard connection labels that have no match).

Any help will be much appreciated!

Schematics

Tøgern
  • 15
  • 5
  • "The FTDI interface works perfectly and reliably if I disconnect the RFM from the mega, so I suppose that it has something to do with this." Can you elaborate on how exactly you are "disconnecting" the RFM from the Mega (i.e. is the RFM still powered by the board under these circumstances)? – vicatcu Oct 24 '19 at 22:44
  • @vicatcu As you suspect I only disconnect the data lines, but keep the power lines connected, so the RFM still consume some amount of power. – Tøgern Oct 25 '19 at 18:19
  • Excluding power and ground, there are (theoretically) six nets that connect the RFM to the AVR: NSS, RFM_RST, MISO, MOSI, SCK, and IRQ. Can you systematically disconnect them to determine which one being disconnected causes the "FTDI intrface [to work] perfectly and reliably"? Ideally you would start by only disconnecting a single one of these while keeping all the others connected. You may have a subtle schematic error which is impossible to detect with the naked eye (an inadvertently connected net for example). Your ECAD tool's ERC might have something useful in its report. – vicatcu Oct 27 '19 at 17:54
  • 1
    I have tried this approach, but success was mostly sporadic, so I concluded that it must have been something else (which it turned out to be - see accepted answer). I have not used the ERC, but will have a look at it - it might provide additional insight. – Tøgern Oct 30 '19 at 11:08

1 Answers1

2

It sounds and looks from your schematic as if you may be attempting to power the project from the FTDI chip's very limited 3v3 regulator.

If that is the case you are probably overloading it, especially when the radio is added.

You should at minimum give your project its own 5v to 3v3 regulator (along with the capacitors that typically requires) if not a dedicated power supply. Of course you need a common ground with the FTDI for communication.

Chris Stratton
  • 33,282
  • 3
  • 43
  • 89
  • This seems dubious, the cable spec suggests it can source 75mA. If it were indeed a power demand problem, the OP would be able to measure it as a voltage drop on the board's 3.3V rail. https://www.digikey.com/en/datasheets/ftdifuturetechnologydevicesinternationalltd/ftdi-future-technology-devices-international-ltddsttl232rcables#pfc – vicatcu Oct 24 '19 at 22:40
  • To correct myself, the Sparkfun Basic 3.3V sources 3.3V from the FT232RL output, which according to its datasheet can supply "Up to 50mA can be drawn from this pin to power external logic if required." Still should be enough to support an idle ATMega328 and RFM95 imho. – vicatcu Oct 24 '19 at 22:50
  • 1
    @vicatcu - people who mistakenly try to power things from an FTDI chip's internal regulator frequently encounter problems. To put some numbers on things, an RFM69 apparently consumes around 16 milliamps to run the receiver (not counting the ATmega or whatever else is on the board, signals unfortunately asserted against pulling resistors, etc) but **up to 130 mA when transmitting**. It's also likely (one might say more probable than not) that the part the asker is using is not actually from FTDI, but some mostly serviceable imitation passed off as genuine) – Chris Stratton Oct 24 '19 at 23:15
  • 1
    At the very least, trying another power supply is an appropriate debugging step to rule out this being an issue. – Chris Stratton Oct 24 '19 at 23:19
  • yes of course that's true – vicatcu Oct 24 '19 at 23:26
  • @ChrisStratton I am powering the circuit from the FTDI 3v3 regulator and I can see how that could be a problem. However, the circuit has worked fine, for periods, even with the RFM fully connected. Of course, this could very well indicate that the power consumption lies near the limit of what the FTDI board can provide. – Tøgern Oct 25 '19 at 18:22
  • @ChrisStratton I have tried using a separate power supply, which did not work in the first place. Removing the resistor on series with the NSS line solved that problem and the circuit now works. Although, because I have previously had sporadic success with the circuit after making changes to it, I will test some more before I come to any conclusion about the cause of the problem. I will return when I have concluded and either accept this answer or elaborate further on the problem (if this is not the correct way to do things here, please let me know). For now, thanks very much! – Tøgern Oct 25 '19 at 18:32
  • The resistive divider on NSS, while mistaken, does not explain the failure of the FTDI to enumerate to the USB host. But overloaded its regulator very much does explain that. – Chris Stratton Oct 25 '19 at 19:48
  • 3
    I have been testing the circuit with external power and it seems stable, so it turns out that the FTDI was indeed overloaded. Thank you very much for your help and comments everyone! – Tøgern Oct 30 '19 at 11:04