Skip to main content
The 2024 Developer Survey results are live! See the results
Super User

Return to Answer

added 160 characters in body
Source Link
jcline
jcline
  • 151
  • 3

run a CPU so hard that the ceramic actually breaks

No, it is impossible to do anything to a CPU in software to cause "the ceramic [to] break". Although it is possible on some CPUs to change frequency or power control modes such that the die overheats, or to change outputs such that the transistors sink or source too much current (which depends how external components are interfaced); either of these will damage the silicon or the pads. The ceramic will be unaffected.

It is also possible on a CPU which has EEPROM configuration registers (sometimes called 'fuses') to brick the CPU. For example embedded processors (not x86 class as in the original question) with internal flash which provide code protect options or other options (for example, Microchip PIC) which, if set improperly, could cause the code to break (if code protect is on, and software is attempting to read program memory, it would return all zeros instead of the actual values). This would 'brick' the system and reprogramming using an external chip programmer could be necessary (maybe even removal from circuit board to accomplish this).

run a CPU so hard that the ceramic actually breaks

No, it is impossible to do anything to a CPU in software to cause "the ceramic [to] break". Although it is possible on some CPUs to change frequency or power control modes such that the die overheats, or to change outputs such that the transistors sink or source too much current (which depends how external components are interfaced); either of these will damage the silicon or the pads. The ceramic will be unaffected.

It is also possible on a CPU which has EEPROM configuration registers (sometimes called 'fuses') to brick the CPU. For example embedded processors (not x86 class as in the original question) with internal flash which provide code protect options or other options (for example, Microchip PIC) which, if set improperly, could cause the code to break (if code protect is on, and software is attempting to read program memory, it would return all zeros instead of the actual values).

run a CPU so hard that the ceramic actually breaks

No, it is impossible to do anything to a CPU in software to cause "the ceramic [to] break". Although it is possible on some CPUs to change frequency or power control modes such that the die overheats, or to change outputs such that the transistors sink or source too much current (which depends how external components are interfaced); either of these will damage the silicon or the pads. The ceramic will be unaffected.

It is also possible on a CPU which has EEPROM configuration registers (sometimes called 'fuses') to brick the CPU. For example embedded processors (not x86 class as in the original question) with internal flash which provide code protect options or other options (for example, Microchip PIC) which, if set improperly, could cause the code to break (if code protect is on, and software is attempting to read program memory, it would return all zeros instead of the actual values). This would 'brick' the system and reprogramming using an external chip programmer could be necessary (maybe even removal from circuit board to accomplish this).

Source Link
jcline
jcline
  • 151
  • 3

run a CPU so hard that the ceramic actually breaks

No, it is impossible to do anything to a CPU in software to cause "the ceramic [to] break". Although it is possible on some CPUs to change frequency or power control modes such that the die overheats, or to change outputs such that the transistors sink or source too much current (which depends how external components are interfaced); either of these will damage the silicon or the pads. The ceramic will be unaffected.

It is also possible on a CPU which has EEPROM configuration registers (sometimes called 'fuses') to brick the CPU. For example embedded processors (not x86 class as in the original question) with internal flash which provide code protect options or other options (for example, Microchip PIC) which, if set improperly, could cause the code to break (if code protect is on, and software is attempting to read program memory, it would return all zeros instead of the actual values).