Jump to content
cde

Stupidest Thing you had to Troubleshoot?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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  :rolleyes:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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 :(

Share this post


Link to post
Share on other sites

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....

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :rolleyes:


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×