Okay... I have a wall wort from a Logitech MX 1000 mouse that is rated 8V-500mA, and, by my meter, delivers 8.59-8.60 steady voltage. When I wire it to the 5V voltage regulator, the regulator reads 5V perfectly.

At this point I was excited to have a wall wort solution that cost me $0. (I even cracked the case open and found that the recepticle is on a tiny board by itself with two wires leading from it -- woohoo!)

Then I put the 5V regulator back into the circuitry for my nerdkit, wired everything up, turned the switch and watched the display constantly refresh itself -- it's as if the MPU is rebooting itself over and over and over... When it's doing this, the meter reads a perfect 5V off the voltage regulator...

When I plug the battery back in, it works perfectly.

From the 9V battery, I'm pulling 27-28mA off the battery; with the 8.6V wall wort it was pulling 25-26mA -- WELL within the 500mA rating of the wall wort.

What am I doing wrong? Do I need a different sized capacitor on the circuit?

Thanks in advance for all help!

MikeDoug

Okay... update. I found that it had NOTHING to do with the power source! It's working fine!!! Yay!

It had to do with the fact that I didn't have the serial cable plugged in, and my in-progress XON/XOFF + internal buffering code is causing the little MPU to panic (hence the seeming reboots!).

That problem is solved -- now to debug this interrupt handling!

MikeDoug

Grrr... I'm 95% there. Figured out my crashing problem -- you don't call reti(), C does that for you in an interrupt handler. :) If you call reti(), expect to crash!

The problem I'm having now is that, for some reason, when I enable xon/xoff flow control in Putty, it does NOT want to listen to any XON commands that I send from the MPU. Therefore it sends NOTHING to the MPU. I can send BREAK, and that DOES get sent -- but that's it. A secondary problem I've noticed is that if I unplug the serial port from the computer, the LED showing data going TO the MPU lights solid, and my MPU spends most of its time in the interrupt handler -- receiving data on an unconnected serial port? More research later!

When I get this figured out, I'll post the changes to uart.c. It's being written such that it can be enabled or disabled when you call uart_init -- though maybe it should be a #define in uart.c/.h such that no extra memory is taken up in your compiled code if you don't want/need the extra stuff... Really the xon/xoff stuff isn't that necessary -- I'm just pedantic, and enjoy a challenge. :)

MikeDoug

Hi MikeDoug,

We have a interrupt-driven UART with input and output ring buffers that we use for some of our work on this end. This may come out in a project video eventually, but we can compare code if you're curious. I can't add anything about your XON/XOFF issue, but let me know how that turns out.

As for the LED glowing when the serial port is unplugged, yes, this is normal. That pin isn't being driven at all, so it can pick high or low. The LEDs on the serial board are driven essentially directly from the TX and RX lines, so they're simply lit whenever the voltage is in the non-idle state. While it's possible to induce some noise on that pin and have that look like data, it's much more common to have it just sit in one position. (But make no mistake, transitions on that unconnected line will happen and may send random bytes to your microcontroller -- good to know if you're making a standalone demo.) Are you sure your code is really spending time in that interrupt handler? If possible, add another LED and have that turn on when your interrupt handler begins, and turn off right before you return from the interrupt handler.

Mike

Hrmmm... couple of things on the flow control...First, how are you sending the XON? 0x11? I guess what I'm prodding at is I haven't really looked into the uart.h, but if the data is being character encoded then the XON wouldn't really be seen as an XON... Though I'm not sure why the break would if that's working, unless there is a special handler for the break??? If I recall a break isn't actually a character at all, but rather just keeps the line low for a period of time... ???

Another thing to ponder... It's been a long time since I've messed with serial stuff, but if I recall, TYPICALLY the XON wouldn't be required from the start... Usually you don't "not" transmit from the start, but rather only stop transmitting when you see the XOFF, and then continue on XON... So maybe that's not your problem at all?

rusirius: That's what I would think ("not needed at start") -- but for some reason putty won't let me transmit.

I'm sending XON/XOFF by writing the 17 or 18 ascii byte code to the line.

mrobbins: I'm almost absolutely certain because the rest of my app is sitting spinning in embedded loops (my version of a sleep -- haven't gotten there yet) -- and when I unplug the serial port those loops take an ENMORMOUS amount of time to return. If the port is plugged in, normal run time.

Mike,

With the RS232 plug removed from the port, my circuit was definitely receiving garbage data on a regular basis -- and my code was spending ALL available time in the interrupt.

However, the "all available time in the interrupt" was because my code would only read a character into the buffer IF there was space -- otherwise it was returning, causing the interrupt to fire again. I added a "oh well, bad things have to happen" sink at the end of the loop if there are still bytes available -- that "solved" that problem.

But it doesn't solve the problem of garbage data coming in on the line. How do I get the device to not read garbage on the port when nothing is connected? I tried using a pull-down resistor on pin 2 of the MPU (the RX line) -- thinking that would cause it to have silence -- but it had NO affect on the circuit (good nor bad).

Thanks! MikeDoug

Hi MikeDoug,

To keep the serial port receive (RX) line idle so that it doesn't cause your interrupts to fire, you'll have to do two things:

1. Remove the yellow wire from the serial board. (Regardless of whether there's anything driving the inverter chip on that board or not, it's going to have a solid output high or low, so you won't be able to "override" it with a resistor unless you remove this connection first.)
2. Add a wire from MCU pin 2 to +5V. (+5V is the idle state for this, and 0 is a start bit. I'm not 100% sure, but if it were actually tied permanently low, I think it'd keep seeing a start bit, eight 0 bits, and then a error because the stop bit should be high. I'd have to dig into the ATmega168 datasheet a bit deeper to figure out what it'd really do in that case.)

Hope that helps,

Mike

Interesting... So the moral of the story is you cannot have the port plugged into the nerdkit and the UART enabled if nothing is plugged into the port itself. I guess I'll worry about that if I ever devise some actual device that I want an RS232 port on -- though the MPU makes it so easy to work with.

MikeDoug

Ah hah! So tonight (well, several nights) I've tried to solve the problem of the unplugged serial port causing garbage data to be received by the MPU on the RX line.

I figured it had to be something with a floating voltage flopping around, and my voltmeter showed that the voltage was sitting around 2.5V with a bit of wavering... So definitely in the undefined area.

So... I thought, what if I pull it down or up with a resistor tied directly to GND or +5. Going directly to the MPU's RX pin didn't have any impact. That's when I thought about the little RS232 board that came with the nerdkit -- that's got the pin that comes directly from the computer. What if I pull the RX pin coming IN from the computer down to GND with a resistor?

Well... It worked! With a 10 Ohm resistor tied between pin 3 of the RS232 port and GND the UART does not receive ANY garbage when its unplugged from the computer's RS232 port, and it does not cause any interference with data reception.

Now -- that all said, I'm not sure if that's the optimum size resistor or not. All I know is that it causes the desired behavior! I'll leave it to the EEs here to tell me if I did right nor not. I just wanted something that would pull that signal down in the absence of any other connection.

I was pretty creative on connecting it too since I don't have a soldering iron yet -- I twisted one end of the wire on the resistor, hooked it under the OTHER resistor connected to pin 3 (on the pin3 side) and then shoved the other end of the resistor down into the GND wire on the 4-pin connector coming from the nerdkit.

Hopefully this will come in handy for someone else (and maybe revision P66380A will have another resistor on it.)

MikeDoug

MikeDoug

I'd suggest somewhere in the 10K to 1Mega ohm range... How about 100K? Right now, with 10 ohms, when the serial port tries to pull it to say +5V, that requires it to source 5/10 = 0.5 amps! That's a tremendous amount of power. (I'm even somewhat surprised that it still works...)

Mike

I switched to a 10K ohm resistor, and it still functions well.

Curiously enough, with my cheap multimeter I could see no real difference in the current draw using either resistor. My test was of flashing the MPU and watching the current as it was writing to the flash.

After I thought about my solution, it dawned on me why trying to use a pull-up resistor at the input of the MPU (pin 2, RX) wasn't working -- because it was being driven quasi-low by the logic chip on the RS232 board. Therefore it was the unconnected input on that chip that needed to be pulled-down to then make the rest of the circuit fall within specifications for the TTL voltages.

Or something like that.

mikedoug--

Something occurred to me in your preceding statement: "Curiously enough, with my cheap multimeter I could see no real difference in the current draw..."

You probably realize this now-- but for others for whom it might not be so clear, multimeters can't measure current. They only work on voltage. You an derive the current change by measuring the voltage drop across a specific resistor, as long as you know the value of the resistor and the voltage in series with it.

BobaMosfet - multimeters CAN measure current (if they have that feature) but they must be placed in series with whatever component you are trying to measure current through. Make sure you have the multimeter on the correct setting and scale before powering any type of circuit and immediate power off and remove the multimeter when you are done measuring. --Steve