I'm not sure why you would want to power a CPU through the clock. However, microcontrollers can get inadvertently powered through the I/O pin protection diodes if you don't hook up power and ground: https://www.eevblog.com/2015/12/18/eevblog-831-power-a-micro...
I once spent two days debugging a microcontroller circuit for my retrocomputing project because of this problem.
The microcontroller was an Atmel ATmega328P I extracted from an Arduino board, I used the chip as an external debugger and monitor. The first function I implemented was EEPROM reprogramming via a programming socket, the code was working without any sign of issue for two weeks, working as intended. I could burn a program to the ROM, plug the ROM in the 8-bit computer and execute instructions. Later I attempted to plug the microcontroller into the system bus of my 8-bit computer to add in-system reprogramming and memory debugging capabilities, so I don't have to plug and unplug the ROM every time I need to reprogram it. I planned to implemenet it by taking over the system bus of via DMA, so the running CPU would handover its the control to me. However, no matter how I changed the code, there were always some strange bugs. RAM reading and writing never worked reliably, there's random memory corruption, and the CPU was never able to continue executing the program correctly after the DMA had finished. It seems there were always some forms of bus contention bugs in the microcontroller, as if the GPIOs pins were not properly tristated/isolated before the beginning of a DMA cycle. But I was unable to find it at all in the code.
Eventually I realized the pin 7, Vcc, was not connected! I miswired the power to an I/O pin. From the beginning, the ATmega328P was operating without the main digital power supply and was sourcing all the power via the ESD diode on the I/O pin, and/or possibly the analog power supply AVCC. I was surprised that it was able to work for two weeks. On second thought, during EEPROM programming, the connection to the chip was direct, and tristate was mostly not used, the MCU had no problem driving it. But in memory debugging, the bus is long and the entire output was tristating on and off during a DMA cycle, the lack of a proper Vcc supply probably made the I/O driver to malfunction, especially the input/output selection, creating unpredictable output state.
Later on in another unrelated project, I encountered another problem due to an incorrect PCB footprint pinout. The 4-pin SMD crystal was connected to the wrong pins - only one side was connected to the chip. there's basically no system crystal at all. But the parasitic capacitance between the crystal pins was sufficient to start a weak oscillation (on the oscilloscope you can see a clock waveform with a very low amplitude, it's not at the proper logic level, as if it's an analog RF circuit), the chip was even able to start its 125 MHz PLL! But the logic was not fully functional until I dead-bugged soldering the crystal the correct way.
Lesson learned: Always double check. Just because the chip has power, doesn't mean the chip is receiving power correctly. Just because the chip has a clock output, doesn't mean the chip is receiving the clock correctly. And finally, if there's an external power-on reset, just because the chip was initialized after you apply power, doesn't mean the power-on reset circuit is functional.
The microcontroller was an Atmel ATmega328P I extracted from an Arduino board, I used the chip as an external debugger and monitor. The first function I implemented was EEPROM reprogramming via a programming socket, the code was working without any sign of issue for two weeks, working as intended. I could burn a program to the ROM, plug the ROM in the 8-bit computer and execute instructions. Later I attempted to plug the microcontroller into the system bus of my 8-bit computer to add in-system reprogramming and memory debugging capabilities, so I don't have to plug and unplug the ROM every time I need to reprogram it. I planned to implemenet it by taking over the system bus of via DMA, so the running CPU would handover its the control to me. However, no matter how I changed the code, there were always some strange bugs. RAM reading and writing never worked reliably, there's random memory corruption, and the CPU was never able to continue executing the program correctly after the DMA had finished. It seems there were always some forms of bus contention bugs in the microcontroller, as if the GPIOs pins were not properly tristated/isolated before the beginning of a DMA cycle. But I was unable to find it at all in the code.
Eventually I realized the pin 7, Vcc, was not connected! I miswired the power to an I/O pin. From the beginning, the ATmega328P was operating without the main digital power supply and was sourcing all the power via the ESD diode on the I/O pin, and/or possibly the analog power supply AVCC. I was surprised that it was able to work for two weeks. On second thought, during EEPROM programming, the connection to the chip was direct, and tristate was mostly not used, the MCU had no problem driving it. But in memory debugging, the bus is long and the entire output was tristating on and off during a DMA cycle, the lack of a proper Vcc supply probably made the I/O driver to malfunction, especially the input/output selection, creating unpredictable output state.
Later on in another unrelated project, I encountered another problem due to an incorrect PCB footprint pinout. The 4-pin SMD crystal was connected to the wrong pins - only one side was connected to the chip. there's basically no system crystal at all. But the parasitic capacitance between the crystal pins was sufficient to start a weak oscillation (on the oscilloscope you can see a clock waveform with a very low amplitude, it's not at the proper logic level, as if it's an analog RF circuit), the chip was even able to start its 125 MHz PLL! But the logic was not fully functional until I dead-bugged soldering the crystal the correct way.
Lesson learned: Always double check. Just because the chip has power, doesn't mean the chip is receiving power correctly. Just because the chip has a clock output, doesn't mean the chip is receiving the clock correctly. And finally, if there's an external power-on reset, just because the chip was initialized after you apply power, doesn't mean the power-on reset circuit is functional.