Stupidest Thing you had to Troubleshoot?

[cde 334]

Today, while trying to create a motion sensing Pantry light, using a HC-SR505 mini PIR sensor, was the overly sensitive sensor. I was trying to power it directly from the Launchpad's 3.5V line, but it kept retriggering and retriggering for no reason! It has a beefy 22

[Tieri 6]

Setting different addreses to two of nRF24L01's. Took me two days to figure...

 

L

[Rei Vilo 695]

Inverse the +3.3V and Ground for an MSP430... Luckily, the MSP430 survived!

[veryalive 49]

@@Tieri           -  sisu

[L.R.A 78]

Power 2 launchpads from 1 USB - used jumper wires to connect the USB powered launchpad to the 2nd one - I did GND-3.3V and 5V to 5V or something weird like that... The thing still worked somehow resenting from time to time. I took me while to notice how the launchpad heat up.

Somehow that launchpad is still going after so many tests and I have just one of those 

[bluehash 1,581]

Forgetting to setup or enable clocks for peripherals. Had to do this for the Stellaris/Tiva-C

[pine 140]

Keep getting error message in CCS saying unable to program the LP (not exactly but something very similar to that meaning). 100% sure the board is connected. Unplugged the USB and plugged in again, restarted CCS and restarted PC. Turns out I tried to program a non-existent 2553 as I moved it out from the LP to a breadboard 

[Fred 453]

I've managed a few. Swapping VCC and VSS on my first etched PCB was a good one. I'm glad I'm not the only one who's done that.

 

I also noticed that a TS430RGC64USB target board that I had supported the F5510 that I was coding for. Great! So I stuck it in and wondered why it didn't work. It turns out that a LQFP48 will fit in a QFN64 socket. It might not fit that well or work, but it goes in.

 

Amazingly neither of these (and probably worse that I've forgotten) damaged the MSP430.

[spirilis 1,265]

I've managed a few. Swapping VCC and VSS on my first etched PCB was a good one. I'm glad I'm not the only one who's done that.

 

I also noticed that a TS430RGC64USB target board that I had supported the F5510 that I was coding for. Great! So I stuck it in and wondered why it didn't work. It turns out that a LQFP48 will fit in a QFN64 socket. It might not fit that well or work, but it goes in.

 

Amazingly neither of these (and probably worse that I've forgotten) damaged the MSP430.

Those darned MSP430's are almost unreasonably difficult to kill! LOL

Makes the FRAM "zombie MCU" idea ever more relevant...

[hlipka 11]

Switching MISO and MOSI for a SPI EEPROM, while building my PicKit3 clone. On the original schematic from the PK3 user guide they are called SDI and SDO, for both the MCU and the EEPROM. So I naturally connected SDI to the same net, and SDO to another one. But in reality SDI was the input on both sides, and SDO the output - so they should have breen swapped. It took me about 3 months to find this out

[roadrunner84 466]

Switching MISO and MOSI for a SPI EEPROM, while building my PicKit3 clone. On the original schematic from the PK3 user guide they are called SDI and SDO, for both the MCU and the EEPROM. So I naturally connected SDI to the same net, and SDO to another one. But in reality SDI was the input on both sides, and SDO the output - so they should have breen swapped. It took me about 3 months to find this out

Pin direction is a pain in the *ss. I've learned so far that the I/O direction description is mostly more informative than the net name....

[Fred 453]

When something doesn't work one of the first things I do is swap I/O pins. Even if I'm pretty sure it's right. In fact this exact thing happened last night between a LPCXpresso1769 and an SD card. (Sorry for the MSP430 infidelity - I'm working on some Smoothieboard improvements.)

[Druzyek 36]

I've have several projects with a 5 pin header for the 6 pin FT232 cable since none of the projects use the 6th pin. One time I plugged the header into pins 2-6 of the FT232 cable instead of 1-5 and my launchpad died :S Also, took a while to get my first MCP23S17 I/O expander to work since the datasheet incorrectly lists the RESET pin as an output, not an input.

[tripwire 139]

I used sprintf on CC2650 and it smashed the stack
 
When I was looking at my code in the debugger the SP was about 2/3 of the way down into the stack, and beyond that the memory all appeared unused. Eventually I spotted a few bytes had been written right at the limit of the stack. Apparently sprintf needs a 510 byte buffer to format the string version of numbers from %d etc. I only wanted to convert a 32 bit value to a hexadecimal string!
 
I think I was spoiled by MSP430 which defaults to "minimal" (s)printf using a tiny internal formatting buffer. It only breaks the C standard, not the stack limit!
 

Keep getting error message in CCS saying unable to program the LP (not exactly but something very similar to that meaning). 100% sure the board is connected. Unplugged the USB and plugged in again, restarted CCS and restarted PC. Turns out I tried to program a non-existent 2553 as I moved it out from the LP to a breadboard

Me too! Sometimes I use the MSP432 or FR5969 launchpads to energytrace another launchpad. When the time comes to reprogram the target I always forget to remove the external VCC/GND jumper wires and reconnect the target to its emulator.

[roadrunner84 466]

printf and friends are very hungry beasts, for integer to hex string and vice versa I prefer manual conversions.

const char *const hex = "0123456789ABCDEF";
unsigned long input = 10;
char output[9];
char *result = output;
for(unsigned int ctr = 28; ctr; ctr -= 4)
  *result++ = hex[(input >> ctr) & 0xF];
*result = '\0';

something like this.