Trouble Receiving UART Output from CW310 FPGA via SAM3X USB Serial

Embedded Security ChipWhisperer Hardware
1

Hello,

I’m using the ChipWhisperer CW310 target board and ChipWhisperer-Husky capture board. I have implemented a simple FPGA design that sends a character (e.g., '0') through a UART interface. I connect this to the SAM3X USB Serial Console and I’m attempting to read the output on my PC through the USB-C data port on the CW310 board.

I program the bitstream using the Python API:

target = cw.target(scope, cw.targets.CW310, bsfile="top.bit")  # Create a target object

I then try to receive the UART output using minicom on my PC:

minicom -D /dev/ttyACM0

However, I don’t see any output. Here are the pin assignments for the serial connection:

set_property -dict { PACKAGE_PIN AB22  IOSTANDARD   LVCMOS33 } [get_ports { tx }]; #IO_L17P_T2_12 - This is an OUTPUT from the FPGA
set_property -dict { PACKAGE_PIN AA24  IOSTANDARD   LVCMOS33 } [get_ports { rx }]; #IO_L12N_T1_MRCC_12 - This is an INPUT to the FPGA

Could anyone provide guidance on what might be going wrong, or how to verify the connection with the SAM3X serial interface?

Thanks in advance!

2

I would start by verifying the baudrate and other UART settings (start/stop bits, parity, etc). It might be useful to route your Tx output to some other pin that you can probe with a logic analyzer, to verify those settings.

3

Thanks for the help - I’ve resolved the issue!

The problem was due to how the clock source for the UART baud tick generator was configured. I had initially used the clock from PLL1, assuming it was the default active clock. However, after further investigation, I found that:

  • Only PLL1 is enabled by default in the ChipWhisperer Python API setup.
  • I was using the output of what I thought was PLL1, but the actual behavior indicated PLL1 and PLL2 are swapped in the API logic or mapping.

After enabling PLL2 manually with target.pll.pll_outenable_set(2)"), the design started working properly and UART characters began appearing on the terminal (minicom).

This PLL confusion was previously mentioned in this GitHub issue:
#10 – PLL assignments reversed in cw310-bergen-board