Weird Prop Mini Problem

RobertDyer

I'm using a Prop Mini Board in a project that controls an RC servo. (It also lights WS2812B LEDs, takes data from a quadrature encoder and outputs to a serial LCD display for user interface. And by the way, all these actions are thanks to you folks who contributed to the OBEX!!) I mounted the Mini (and all the other components) to a PCB I designed with Eagle; all of the hardware functions appear to be working just fine. I have my software working, and it runs on the Mini successfully - taking data from the user who turns the encoder, displays a decimal value on the LCD, and outputs the pulse-width to drive the servo. I've programmed the EEPROM and it all works great UNTIL... I cycle power.

Once I cycle power the serial data to the LCD goes crazy: sending a repeating string of characters containing 5 spaces, a capital "Q", and the character representing a hex D1, none of which are sent to the display by the program when it's running normally. Hitting RESET doesn't help. Cycling power again doesn't help. The only way for me to return the device to proper functioning is to re-connect the Prop-Plug (it has to be connected to my PC on the other end of the USB cable) and then cycle power. With the Prop-Plug connected it comes up on the downloaded EEPROM program even without downloading the program to RAM again or any other PC action. If I disconnect the Prop-Plug, it continues to operate correctly, as long as I don't cycle power. I can even RESET the CPU with the Prop-Plug disconnected, and it will come up running on the program in the EEPROM correctly. But once I cycle power it ALWAYS sends bad data to the LCD (PIN17 through an Adafruit level-shifter). However, even when the serial data is bonkers, the encoder input (PINs 0 & 1) still works, and the servo output (PIN16 through the same level-shifter) still works. I'm powering the entire PCB assembly using a Parallax 7.5V wall wart, through the regulators on the Mini. The 3.3V and the 5V are both dead-on and steady.

So... I know this is weird problem. I don't think it's my code, and I don't expect you guys to sort through it. I'm just wondering if any of you have had problems with the Prop Mini acting flaky. Or more importantly, if you can explain how reconnecting the Prop-Plug is returning the board to sanity, but only after cycling power. That might lead me to the solution. Any other suggestions for debugging would also be great!

Thanks for your time.
Robert

jim N8RHQ

do you have any delay after you initialize the LCD? I usually use something like:

LCD.Init(TX_PIN, BAUD, true, 2) ''initialize LCD_DisplayDriver.spin
waitcnt(clkfreq / 100 + cnt) ''pause for initialize

sometime the LCD flakes out if you start sending data at it before it's ready.

RobertDyer

Thanks, great idea! I have a delay in there just as you described. I've actually increased it to 1 second now just to be sure, and no change.

I should also mention that I have exactly the same problem if I power the board with an 8V LiPoly battery pack as I do with the wall wart. Thought it might be some kind of grounding issue through the USB Prop-Plug, but probably not.

Keep the suggestions coming.
Robert

JonnyMac

So... I know this is weird problem. I don't think it's my code

Hard to tell without seeing the code....

If it is a serial display, what pin are you using for coms? If not a problem pin (28..31), then I would suggest putting a pull-up to 5v on the serial line and user open-baud comms. This will ensure that it sees a "1" at the proper level. A 10K pull-up will be fine.

If it's a parallel LCD in 4-bit mode, you can get junk on a reset because the display is already configured for four bits, and the initialization code starts assuming eight. I'm working on a commercial project that had this issue. Right after calling the start method I do a short loop of calling the method that clears the LCD -- this sorts everything out.

RobertDyer

Thanks Jon. (And thanks for all your OBEX objects. I'm using many of them!)

I'm using a LinkSprite serial LCD on P17 of the Prop and I'm driving it through an Adafruit 4-channel FET level shifter board to make sure the signal voltage level isn't a problem. It's running at 19_200 baud.

I'll include the code when I'm back on that machine (hopefully tomorrow).

Question: Do I need a pull-up on the RESET pin, or does that happen internally?

Robert

Ltech

Massa trouble ?
I have it one time, I forgot one connection to ground, but when connected trough pc I get ground trough ground of USB .... Stupid, but spooky

RobertDyer

Thanks guys, I figured it out. Woke up this morning at 4am and was thinking about your responses. I remembered some things about the LinkSprite.

It defaults to 9_600 baud, but I've re-programmed it's onboard EEPROM to use 19_200 baud. However, if you send data during it's splash screen (the first 1/2 second after power-up) it reverts to the default baud rate. The "garbage" I was getting on the LCD was due to a baud rate mis-match. So, the delay I needed is before initializing the device, not after. My guess is that the Prop-Plug holds the RESET signal low on power-up for some amount of time. This was enough for the LinkSprite to clear the splash screen and get on with business.

So thanks for being there for someone to bounce ideas off of. Couldn't have solved it without your input.

Robert