7
The problem you face is that USB-C cables are not wired 1:1 as you have assumed. Furthermore not all USB-C cables are made equal.
This is one of the many reasons why you should not use standardised connectors for non-standard purposes.
Firstly you need to be sure that it is a full-featured USB-C cable, one which is intended for use with USB3.x and so ...
5
The issue is likely due to the huge amount of capacitance you've put on the data lines due to your clamp diodes. USB requires very low capacitance zener diodes - those huge 600W clamp diodes you have selected are likely distorting the data waveforms to the degree the USB device cannot enumerate.
If you remove D301 and D302 I suspect it will start working.
4
No, the FTDI FT232RL, nor any other UART to my knowledge, can be set to the framing mode required by your chip.
However, it is not a hardware framing selection problem, but a software data encoding problem which is easily solved.
After all, the datasheet does mention that the chip is compatible with UART serial data format. It just does not mention an ...
3
Yes. The web page how to use the board also confirms this:
The Basys3 board can receive power from the Digilent USB-JTAG port (J4)
3
It's an FPGA. You can have an UART on as many pins as you like until you run out of logic elements.
3
If the signal has a frequency of 1 Mhz, does that charge the capacitor
faster?
No.
is it possible to discharge the capacitor by zerocrossing the signal?
Sure, if you do it with the right timing.
Secretly I hope the capacitor does not effect the UART signal, because
adding a circuit for zerocrossing adds (logically) more components to
the PCB.
The ...
3
Secretly I hope the capacitor does not effect the UART signal, because
adding a circuit for zerocrossing adds (logically) more components to
the PCB.
Well, your secret is out now and be prepared for disappointment. The capacitor will wreak havoc on a UART signal because it will try to remove the DC offset of your UART signal. Given that a UART signal ...
2
How about: shift your TX data up by 1 bit and set the LSB to 1. This will set the ‘ST2’ bit position to 1. You’d then continue to use 8N1 UART setting as normal on the FTDI side.
As it is your driver needs to do special data formatting to form the 2-byte address / data sequences, so one way or another your host application has to twiddle bits.
1
It's been many years since I used nRF. So, don't get mad if I say wrong. :)
I remember I had to update the nRF device internal firmware, and the manufacturer's (Nordic) update procedure worked. I forgot what port I used, but it was not JTAG.
See if this link leads, as a starting point, to anywhere to your answer page: Updating the modem firmware, ...
1
simulate this circuit – Schematic created using CircuitLab
The charge of a capacitor is the integral of current that has flown; that's all there is. So, no, a 1 MBd UART signal doesn't charge a capacitor faster. On the contrary, for high-speed signals, you'd be sure that your receiver has a defined impedance, and that will inherently be a DC path to ...
1
That is a rather weird device.
The second start bit must be a 1, and that is followed by three address bits, then four data bits. To talk to it from a normal UART, you set the least significant bit of the byte to 1, then the next three bits are the address, LSB first, and finally four data bits, also LSB first. You need to send two bytes to pass a single 8 ...
1
NDTR == 0 means that DMA transfer is completed. I don't know how you process USART reception buffer, but NDTR == 0 case probably indicates an error. This may happen if more bytes than you expected end up in your USART receiver before you process them. In this case, DMA stops (which is actually a good thing because it prevents DMA to overflow data to ...
1
Without my hands on it, I guess problem can be found somewhere else than the given circuitry itself. See if you like my observations.
1)TMUX7219 datasheet is missing information about logic input current, or my eyes just are missing it.
2)We can assume TMUX7219 operates with EN & SEL disconnected to route S1 to D, according to TMUX7219 datasheet "...
Only top voted, non community-wiki answers of a minimum length are eligible
