cde

Stupidest Thing you had to Troubleshoot?

17 posts in this topic

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

bluehash likes this

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 

cde likes this

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:

roadrunner84, tripwire, cde and 2 others like this

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.

tripwire, cde and spirilis like this

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

cde likes this

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

cde likes this

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

cde likes this

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

cde likes this

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.

cde and tripwire like this

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.

cde likes this

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.

spirilis and zeke like this

Share this post


Link to post
Share on other sites

Just yesterday I was battling with a atmega328pb (more internal peripherals than standard atmega328p). Specifically I wanted to use the UART1 port to receive data from a GPS. My old setup uses a software serial implementation.

 

After a whole day of debugging this second port not working. I'd concluded UART0 TX and RX worked fine. UART1 TX worked fine, but no RX. My scope was showing the serial stream from the GPS. All the pins were correct.

 

Turns out the AVR wasn't registering the HIGH level from the GPS (3v) as HIGH because it's running from 5v. /facepalm

Didn't even consider it a factor since the atmega328p worked with the 3v signal fine.

 

Adding a level translator and everything just works.

roadrunner84 likes this

Share this post


Link to post
Share on other sites

Just yesterday I was battling with a atmega328pb (more internal peripherals than standard atmega328p). Specifically I wanted to use the UART1 port to receive data from a GPS. My old setup uses a software serial implementation.

 

After a whole day of debugging this second port not working. I'd concluded UART0 TX and RX worked fine. UART1 TX worked fine, but no RX. My scope was showing the serial stream from the GPS. All the pins were correct.

 

Turns out the AVR wasn't registering the HIGH level from the GPS (3v) as HIGH because it's running from 5v. /facepalm

Didn't even consider it a factor since the atmega328p worked with the 3v signal fine.

 

Adding a level translator and everything just works.

 

Yeah, VIH levels are tricky. The AVR Mega line is supposed to accept VCC * 0.6 as input high, but that's the minimum. So 3 at 5V. But if your at 5.1V and the input is at 2.9V...

tripwire likes 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