Electronics > Open Source Hardware

Open Source HW RF Signal Generator

<< < (28/28)

SaabFAN:
Today I reflowed the chip during a livestream - It didn't go according to plan... I made a mess with the solder when I installed the Chip again and had a lot of solder bridges on the chip. After finally getting rid of them, I realized there was a short on the supply-rails. Where I couldn't tell. Removed the chip again, as well as several capacitors and short was still there. So in the end I isolated the affected supply-rails (desoldered regulators) and zapped the shorted rails with 15 Amps. That cleared the short (without any smoke btw.) and I installed the chip again, as well as the all the caps.

When I tried to communicate with the chip, however, I couldn't read the registers anymore. So all the heat I applied to the chip must have killed it in the end.

But now to the not so bad news: The solder on the center pad had not melted when I desoldered the chip the first time. It looked like it had been squished a bit, but the metal on the bottom of the chip was completely dry. So there was probably not a good connection between the pad and the board, if there was any.

I have now ordered replacement-chips on ebay, but they'll take at least a month to get here. So until then, I'll have to continue without the AD9957.

I'm still not entirely sure where that short circuit came from btw. Can vias create short circuits to inner planes if heat is applied to the board for too long? As I said, I zapped the traces with 3.3V 15 Amps from my bench-supply (one lead to Ground, the other to the supply-rail. I didn't see sparks or noticed any smoke.

uski:

--- Quote from: SaabFAN on October 28, 2020, 12:48:40 am ---I'm still not entirely sure where that short circuit came from btw. Can vias create short circuits to inner planes if heat is applied to the board for too long? As I said, I zapped the traces with 3.3V 15 Amps from my bench-supply (one lead to Ground, the other to the supply-rail. I didn't see sparks or noticed any smoke.

--- End quote ---

For next time, if you have a thermal camera, you can put a low current into the short (just a few mA is enough, depending on the model/sensitivity of your camera) and probably see it with the thermal camera.

Interesting project BTW. I found this while searching information around the ERASynth Micro which I find is not good enough. Hopefully you will finish your project and make it available :)

SaabFAN:
The new Chips have arrived and I still see the exact same behavior.

So I decided to rebuild the part of the board with the AD9957-Chip on a small daughter-board that I can just mount into the existing mounting holes on the main board.
Connection will be done with thin wires that will be shorter than 2 cm. So signal integrity on the parallel interface shouldn't be too much of a problem. If it is, I can still reduce the speed of the parallel bus.

What I have changed for the daughter-board:
- More Capacitors - 100nF for each pin and 1uF every 2 pins, plus 10uF for the entire rail.
- Linear Regulators for every rail, including the 1.8V Supply for the digital Core
- 2.5mm hole underneath the chip to be able to inspect and if necessary reflow the solder of the exposed pad
- Fixed the Reference-Clock Input (Single Ended input terminated into 50 Ohms and the complementary input capacitively connected to ground)

With a little luck, JLCPCB will also have the AD9957 in stock by the time I order this daughter-board, so I won't have to solder everything myself :)

Apart from getting this daughter-board, I have thought about removing the series terminators on the signal traces from the FPGA to the AD9957. Last time I measured there I was able to see some ripples, but I wasn't sure if they were caused by a measurement error or if they were actually there.

SaabFAN:
Finally found the Problem - IT WAS IN MY F****** READBACK-FUNCTION!  :wtf:

Hardware is OK, and the Chip is being programmed OK.

But this piece was wrong:

--- Code: ---
HAL_GPIO_WritePin(AD9957_CS_GPIO_Port, AD9957_CS_Pin, GPIO_PIN_RESET); // Select the Chip
HAL_GPIO_WritePin(AD9957_IOUP_GPIO_Port, AD9957_IOUP_Pin, GPIO_PIN_RESET); // Set the IOUpdate-Pin to LOW
HAL_SPI_Transmit(&hspi2, &receiveAddr, 1, 800); // Send the Data to the Chip via SPI2
HAL_SPI_Receive(&hspi2, regBuf, reglength, 800);
HAL_GPIO_WritePin(AD9957_IOUP_GPIO_Port, AD9957_IOUP_Pin, GPIO_PIN_SET); // Set the IOUpdate-Pin HIGH to load the data from the shift register into the register set by the instruction-byte
HAL_GPIO_WritePin(AD9957_CS_GPIO_Port, AD9957_CS_Pin, GPIO_PIN_SET); // Transfer over, Deselect Chip
--- End code ---

The Correct way is this way:

--- Code: ---HAL_GPIO_WritePin(AD9957_CS_GPIO_Port, AD9957_CS_Pin, GPIO_PIN_RESET); // Select the Chip
HAL_GPIO_WritePin(AD9957_IOUP_GPIO_Port, AD9957_IOUP_Pin, GPIO_PIN_RESET); // Set the IOUpdate-Pin to LOW
HAL_SPI_Transmit(&hspi2, &receiveAddr, 1, 800); // Send the Data to the Chip via SPI2
HAL_GPIO_WritePin(AD9957_IOUP_GPIO_Port, AD9957_IOUP_Pin, GPIO_PIN_SET); // Set the IOUpdate-Pin HIGH to load the data from the shift register into the register set by the instruction-byte
HAL_SPI_Receive(&hspi2, regBuf, reglength, 800);
HAL_GPIO_WritePin(AD9957_CS_GPIO_Port, AD9957_CS_Pin, GPIO_PIN_SET); // Transfer over, Deselect Chip

--- End code ---
I/O-Update BEFORE Reading Data.
After I corrected this, the Chip behaves correctly.  |O  :-DD :palm:

Which means I spent hours of troubleshooting and about 100€ for new Chips and a Daughterboard for nothing >:(
Anyone here who wants a breakout-board for the AD9957? LOL

radar_macgyver:
 :-+ Glad you found the issue! Do you see the 38 kHz modulation on SYNCOUT with the new board?

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version