UCB promlem.... again

I looked at as many of the UCB problem posts as I saw that might be related, but only got so far.
I am using board 1.2.1 with the 16f648a with the premade hex files (firmware-0071219) on WinXp.
1. I know my connection is working with echo back by shorting it as far as the pic pins 7&8 on the UCB.
2. I changed the prefs in the software as needed for the right com channel.
3. All the java files are in the right place (I was getting a different error until I fixed this)
4. I am getting info back from the chip apparently, but it's not working properly.

With the tx/rx not connected all I get is:
RX ffffffff Receive error, re-sending: Timeout receiving byte 0->8: 0
TX 0->8: 0

with the tx/rx connected to the board properly I get this instead:
RX 0 0 0 0 0 0 0 0 ffffffff Receive error, re-sending: Timeout receiving byte 0->8: 0
TX 0->8: 0


As soon as I disconnect either cable, those zeros dissapear.

I haven't seen this error on the forum yet, but since it's actually getting something different if the board is connected does that mean it could be a firmware issue?
Has anyone tried the 648a firmware with the "stepper exerciser"?
my tools->diagnostics->basic comm test also isn't doing anything, I don't even get any error line in the cmd window...


Please help

I'm working with the newer Ardino setup...

But I can say that "tools->diagnostics->basic comm test also isn't doing anything" -- same here. It seems non functional (I'm on SVN 1217). However, my boards are working - as I can use the Reprap.jar to turn on the cooler (fan) control. But the "basic comm test" does nothing.

Dylan,

I'm also using the v 1.2.1 Universal Controller boards. I have been getting these errors intermitantly myself. I've tracked the problem down to connections between the Power Comms and the UCB.

Check that your Tx->Rx connection from one board to the other is correct. I have the Tx wires from the left side of a given set wired to the left side of the corresponsing Rx set. IE Left to left, right to right.

Another simple test is to short the Tx Rx pair on the Power Comms together--I think they described this in the instructions for testing it. Do that and see if you still get the errors.

Also, I found I had success with restarting Ubuntu if I kept getting this error. For some reason I think the system is saving a setting or something that doesn't allow me to fix things if I do them wrong once. If I restart after getting an error, I can get the system to work again.

Also make sure that you have the boards powered up before you start the host software. I don't know if you need to have it powered up that early for sure but I know that if you don't have it powered up before you try and start the Stepper Excerciser then you get this sort of error.

I haven't had any luck myself with the Basic Comms Test either.

Let me know what your results are from trying my suggestions and we'll try and track this down to a concrete thing.

Demented

I've confirmed that everything is wired properly several ways. When I bridge pin 7&8 (tx rx) on the UCB PIC area I get echo back from my terminal. I physically rechecked the wires. The picture below shows the error. The top part in red only appears when I have the board wired properly. The bottom part in blue appears any time my any of my tx, rx, power lines are not connected.... basically any time it's not correct, it's what the blue part shows.



I was also getting some really funky code when the java txrxlibrary wasn't installed properly, so that's fixed now too.

Since hardware and software are fine I am left to believe the only other option is for the firmware to be a problem or the host software.

I'd like to test this specifically. What is the host software actually sending when it tries to do the test? If I send this with my terminal software I should be able to see what gets sent back and see if it's the right thing.

Please let me know. I used the new stepmotorx.hex file for the 16f648a.

thanks
Dylan

Are you setting the com port correctly in the Reprap java software? If the echo works with outside software... maybe just not opening the port correctly.

Dylan,

RoundSparrow's idea first. Then burn your Pic with the old stepmotor.hex file and not the stepmotorx.hex file to see if that works. I'm using the older ones and I can get it to work. Also might think about trying another of the new driver firmware: stepmotory.hex, etc. That'll narrow it down some too. I had some problems with my first run because the chip didn't burn properly. Had to do it a second time and then things started working right.

Anyway, hope that helps. Marry X-Mass!

Demented

under prefs it says "COM1" under com port, it did have the "/dev" thing before but I changed that before I even tried the first time since that's supposed to be for linux or something.
Actualy I just found out that the red section above happens when tx is connected to tx. So I guess I screwed up there since tx on pcomm is supposed to be connected to rx on UCB and visa versa.
I tried the stepmotor.hex from the 1114 file and both the x and y from the 1219 file and they all give the same error.
I might just end up having to build a linux machine just for reprap. Do you think fedora 8 would work ok (if I do it)?

Try the Reprap LiveCD before going that far. You just boot off the CD and it will run an Ubuntu environment with the basic reprap tools in RAM. If you can't get it working using that then its not a host software issue and you're looking in the wrong direction. You can download it via bittorrent (the .torrent seed is on the sourceforge site).

First of course though, try the echo-back idea. Open up hyperterminal etc. and see if what you type to that port appears on the screen.

Most of my issues that have been hard to diagnose like this end up being physical hardware issues, mainly with the wiring (although I did have a brain fart issue when I did a echo-back test with the PIC chip inserted when it wasn't supposed to be).

Also, I can also confirm that the Basic Comms test does nothing for me (with everything wired up and the PICs in place).

Reece is right, you really shouldn't need to use Linux to get your UCBs working! If they work in one host OS, they will work in the other. My strong suspicion is that you have either a wiring or soldering issue somewhere, and I'd double and triple check those before trying a new OS!

If you *do* decide to try Linux (and if you *want* to learn a new OS, go for it!):

One way to obtain and install that is relatively easy for Windows users (with an Internet connection) is to install using WUBI. It is still in beta, but works for me. Basically it installs Linux as a set of a few (large) files within your XP filesystem, and creates a boot menu so you can boot Linux or Windows.

Since it is "beta", I'd back up my Windows PC before trying it... but it avoids the need to repartition the hard drive or acquire a second hard drive or second PC.

I have successfully run the Reprap host software on a WUBI-installed copy of Xubuntu 7.04. In fact I have used this setup to do some development and testing of .deb packages here.

To install using Wubi, you would:

(1) Back up your windows data (unless you truly don't mind if it accidentally gets destroyed)
(2) Download the wubi installer from [www.wubi-installer.org] (link is to a web
page, display the page and click on the "Download (beta)" button towards the
top right of the page)
(3) Run the wubi installer, select Xubuntu and a username and password
(4) When you click install, it will download the Linux CD image it needs and do all the work.
Just be patient while it does this...!
(5) Reboot and select Ubuntu at the boot menu.
(6) First time, it will go through the actual Linux install process, automatically.
More patience here...!

No need to burn a CD, no command line stuff needed at all... it "just works". You can also uninstall WUBI (using Add/Remove Programs) later, and it will disappear without a trace :-)

But first, re-check your wiring and firmware at least one more time :-)

---

---

Jonathan

I had already made the live CD but hadn't used it yet. I just tried it and it didn't work either. The prefs had the /dev.... something as the default com port which didn't work, I tried com1 also just in case, but I'm pretty sure that's a windows only thing. I scanned in my board so you guys can see what I did and if you see anything wrong (I left the txrx lines off for easier scanning).




I jumped the txrx pins of the pcb header (pin location found on the official site of [ww1.microchip.com]).
To the best of my knowledge my hardware is fine based on:

1. all the power LEDs come on
2. testing power with meter works fine
3. programming the chip keeps the debug LED lit
4. shorting those pins gets echo in terminal program proving the computer can talk all the way to where the chip sits.
5. echo only appears when board is powered proving that auto echo or "display what I typed" option or whatever it's called is not on.

I also tried the older stepmotor hex file along with 2 of the newer ones with no difference in results.



hopefully that clarifies things a little more.

Edited 1 time(s). Last edit at 12/25/2007 08:59PM by Dylan.

It's easier to discuss issues and try to help if you follow the set of tests on our Wiki pages (and, if necessary, nophead's more detailed set for the PowerComms board, which are linked to from the wiki) and refer to them that way.

Looks to me as though there are two main possibilities in your situation: (a) some sort of wiring/soldering issue and (b) bad PIC, or PIC firmware not doing its job in some way.

There is also (c) serial port misconfigured, but that seems a stretch since you are testing with the Reprap host software at this point! Though a bps rate mismatch could explain why jumpering things allows echo but the PIC doesn't seem to talk sensibly! We need 19200 bps, 8N1, no hardware handshake. [Are you using a real serial port, or some sort of USB to serial converter, and if the latter, which one?]

Of those possibilities, (a) seems likely to me, then (c), then (b). Every other time someone has had an issue at this stage of testing (All PowerComms tests pass, UCB Tests 1 and 2 pass, but UCB Test 3 at [reprap.org] fails ) the issue has ended up being wiring or soldering, as far as I know.

BTW, since UCB Test 3 apparently fails for you, why does your UCB have the diodes, P9 and the L298 already soldered in it? They are added only after Test 3 passes, if you are following the instructions, I think. Did your board pass UCB Test 3 at some point?

One way to check for a firmware or PIC issue is to flash a spare PIC with an older firmware release and test with that, as someone else already suggested. It's worth trying once you are convinced the issue isn't wiring/soldering.

There is also a set of test firmware around somewhere in the forums (created by nophead I think) that sends a preprogrammed test message at various baud rates, etc. which you might want to try if using a different PIC with older release firmware doesn't help us figure this out.

Jonathan

---

---

Jonathan

I was following the tests on the wiki, the reason this one has the diodes on already is because I saw a post that someone only got past that problem after putting in the 4.7k resistors which is part of making it the stepper board, so I did all of that. I have 4 other UCBs that don't have any of that stuff and I have a few extra PICs so I'll try to mix and match all of them to see if I can get any of them to work.

Why would I need to look at nophead's PowerComms board post if I have that working already.

(a) some sort of wiring/soldering issue---- I wouldn't think so, I'm fairly good at that and the echo and LED tests worked, but I can check this with using the other boards.
(b) bad PIC, or PIC firmware not doing its job in some way--- I've already used a few PICs but I'll use them all in a combination of old and new firmware
(c) serial port misconfigured--- yes, this was a problem, but didn't fix it. The UCB page at test 3 should probably point out that windows users need to go into the hardware control and change the baud rate in there for their com port. I was assuming the software was doing that automatically since all of my terminal programs specifically ask you or have a default that can be changed, but that option isn't in the host prefs, so I just assumed.
it was 9600 8bit no parity and no flow control by default so the only thing I changed that the baud rate. and I'm using an actual serial cable.

I'll post back with the new finding and if I can find the test firmware.


Dylan

ok, I ran a few tests

(a,b) wiring/soldering issue---- I tested with 3 other boards and 3 other chips with the older firmware and same problem.

I found the firmware and I think it was in the link where you and nophead were trying to help Kia... the files were from emf by the way (http://forums.reprap.org/read.php?12,3874,4175,quote=1)

the LED blinking test worked fine.
the TX test sent back garbage letters to my terminal
the RX test made the LED blink the right number of times

BUT... I only got the TX and RX to work properly when the pcomm and UCB were connected like
TX to TX
RX to RX

wft? this is the opposite of everything I've read before. I'll check my pcomm board and see if anything is messed up there, but so far all the physical stuff looks ok, and the firmware tests work, but....

well, that's the update, it works, but doesn't work....



edit1: ok, I tested the txrx on the pcomm board and apparently ... The LED connected to the RX connection (D2) is the one that lights up when sending data from the terminal program... does this mean the silkscreen is wrong?
(my original problem is the same though, I've been trying both ways when I was doing the testing. this also means though that my test at the top (the cmd lines in red) are correctly connected)

Edited 1 time(s). Last edit at 12/26/2007 12:25AM by Dylan.

Well, that's progress... sort of!

I don't have that recent a PowerComms board, mine doesn't have the TX and RX LEDs on it.

One more idea before I go to bed: I wonder if your serial cable could be crossing pins 2 and 3 ?? You should be using a straight-through cable from the PC to the PowerComms board.

Jonathan

---

---

Jonathan

That's a good idea, I crawled under my desk to unplug it and tested the relevant pins and pin 3 is the same on both ends (or at least that is what my multimeter says) I tested the other 2 on each side just to make sure, but it does look like it's a straight through cable.

I was thinking this shouldn't be a problem, just change the cables, but the 232 chip might not like that (never used one before).
If I can get the txrx tests to perform correctly that means that it should be firmware, host, or com settings. I'll try the live CD tomorrow with all the tests I've done and using the 1114 firmware and see if that works, if it does then it's a windows installation problem (which should be fine), if it doesn't then if might be a firmware/PIC interface problem.

this is frustrating
thanks for the help though

Dylan wrote:

> That's a good idea, I crawled under my desk to unplug it and tested
> the relevant pins and pin 3 is the same on both ends (or at least
> that is what my multimeter says) I tested the other 2 on each side
> just to make sure, but it does look like it's a straight through cable.

OK, well, it was worth checking.

> I was thinking this shouldn't be a problem, just
> change the cables, but the 232 chip might not like
> that (never used one before).

Each buffer/level conversion in the MAX232 works in just one direction -- relevant pins are labelled either IN or OUT, and changing the level on an OUT pin won't do anything to its corresponding IN pin :-)

However, the PowerComms board is pretty well tested at this point, and (barring a totally disastrous mistake in the latest revision of the PCB, which seems unlikely, but which I can't test for from here) it's not clear why it would suddenly become a source of problems. No-one else has reported swapped TX and RX within it that I know of. And since the MAX232 is "one way", getting echo by jumpering Tx and Rx on the UCB *should* indicate that things are "right way round" on the PowerComms board...

Can you either describe in detail, or post a diagram of, exactly how you are wiring things together? I don't know what I'm looking for as a wiring mistake that would cause what you are seeing... but it might trigger a new idea for ways to test further...

Just in case it helps (there's probably no new info here): you should wire up:

(1) power to the PowerComms board (one molex connector from a PC power supply),
(2) power from PowerComms to the UCB (two wires, +ve and ground),
(3) a single wire from Tx on the PowerComms to Rx on the UCB,
(4) another single wire from Tx on the UCB back to Rx on the PowerComms board to complete the communications ring. Add
(5) a straight-through serial cable from PC serial port DB9 to PowerComms DB9,

and it should all "just work"!!

> I'll try the live CD tomorrow with all the tests I've done and
> using the 1114 firmware and see if that works,

OK. If Bruce's LiveCD includes the poke test tool, you can try that and get another data point that way. We *really* need to get poke ported to Windows, too!

> this is frustrating

Yes, it is. Issues at this point are exactly why we added the extra LEDs on the new PowerComms board... if it ends up that adding them (i.e. the new PowerComms PCB layout) somehow *caused* this issue for you, that would be very frustrating!!

---

---

Jonathan

I did a video to show what I've been up to, this should show the main things.
It's hard to tell that I actually swapped the wires in the last test that actually works, but I did.



I haven't tried the live cd poke test (if it has it).

OK. Took multiple attempts before I could play the video (is photobucket supposed to be Linux/firefox friendly? It doesn't seem to be!).

My conclusions are that (never mind the apparent reversal weirdness, which I can't explain at all!) in the final stage of the video, using EMF's rx_test LED blinking firmware, you are successfully sending serial data from the PC to the PIC (via the MAX232) and it receives that serial data just fine, and acts on it. The remaining problem at that point seems to be getting serial data back from the PIC to your PC.

If you leave the setup wired that way, and (power down first of course!) swap the PIC for one programmed with his other test firmware, the tx_baud one that sends stuff from the PIC to the PC at various speeds, what do you see in the terminal emulator? At any point do you see the

Transmitting at 19200 baud (correct)

message appear? Also, which LED (TX or RX) on the PowerComms board flashes when tx_baud firmware is running?

If you do see the message ... then both directions of serial data seem to be working!

If not, then the remaining issue is apparently somewhere between the TX serial output of the PIC and the receive side of the desktop PC serial port. Maybe we can check wiring and voltages in various places between that PIC pin and the DB9 connector on the PowerComms board...

If we need it, do you happen to have access to a scope? Brrr, I'm a software person really, but I'll try to work with you on this as far as I can :-)

Jonathan

---

---

Jonathan

this is what my terminal program gives me at 19200

Quote

Can you get access to a scope? it is possible that the PIC has had its calibration register for the on board oscillator adjusted by mistake this could possibly push the board rate just enough off the mark to not work. This is unlikely due to multiple PIC's but a consideration if your programmer is setting this register some do!

The only way to properly test baud rate is to scope it which is not always possible i understand but if you can beg steal or borrow one it will probably solve the problem in 1/2 hour

---

Ian
[www.bitsfrombytes.com]

I'm assuming you mean oscilloscope and not microscope or some other type. There are probably some at the local college, but I gon't know if I can get in there.
My programming software give different options for osc (bold is what the tx_baud seems to set as the default):
RC: CLKOUT on RA6....
RC: I/O on RA6...
INTOSC: CLKOUT on RA6...
INTOSC: I/O on RA6...
EC
HS
XT
LP


any idea what it should be? HS and XT were the ones I was using on my 18f but I forget if that was with the 20mhz osc.

That setting is correct the issue is that the PIC has a calibration register (OSCTUNE) to allow you to fine tune the internal oscillator this is factory set and very rarely needs altering but some programmers have the ability to alter this setting and it would cause the oscillator to run at the wrong frequency which in turn would cause the baud rate to be wrong, RS232 is allowed a 10% timing error but running at 4MHz your error is already 8.51% so a small shift might cause a problem and if it's border line it might work one way and not the other.

The tunning register can alter timing by +-12.5% so could pull the system out of range.

This option is unlikely but just a consideration as all else seems to be failing but you do need an oscilloscope to really nail this.

When ever I have comms problems I always scope first as it just lets you know that part is OK you can check levels timing etc

---

Ian
[www.bitsfrombytes.com]

Asuming I could get my hands on one, how would I use it. Would I need my pc hooked up, or could I just keep it on the tx_baud test and use that without a computer to hookup to?
Are there any tutuorials or anything?
It would be easiest if I could just take my box with power and 2 boards to the college.
I wouldn't have thought that all of the PICs are off, but if it's a factory setting it might make sense that they were all ordered and made from the same batch, I don't know.

I'll probably try making my own test program in basic and see if I can get that to work before I try getting ahold of someone at the college.

> BUT... I only got the TX and RX to work
> properly when the pcomm and UCB were connected
> like
> TX to TX
> RX to RX

crap. i think you may have discovered a bug. i'm not 100% sure but i think we may have the silkscreen switched around on that board. that would really suck, but easily fixable as a note in the instructions.

Dylan wrote:

> Asuming I could get my hands on one, how would I
> use it. Would I need my pc hooked up, or could I
> just keep it on the tx_baud test and use that
> without a computer to hookup to?
> Are there any tutuorials or anything?

I don't think anyone has written up how to use a scope to look for
this, it's a first-time issue (maybe second-time, if this is what
also bit Kai a few months back, I suppose). Sounds to me as though
Ian is well-placed to guide you through that process.

One other way forward could be for one of us to mail you a spare PIC,
that we have programmed up and tested. Where are you in the world? Maybe
someone among us is near you and has a spare PIC they could mail to you --
that could be considerably easier than getting permission to use a college
oscilloscope and learning how to use one, and of course you could mail
the test PIC back to its owner when your are done testing with it.

Looks like you are doing really well at bug-finding: the (probably) mislabelled
TX and RX LEDs on the PowerComms board, *and* whatever is causing the "garbage received from PIC" issue :-)

Jonathan

---

---

Jonathan

I've gone through a bunch of tests and pretty much confirmed the reversal on the silkscreen.
On the middle part of the video you can see the RX LED light up with no cables attached which can only be done transmitting from the pc side. Like you said though, not too big of an issue, just swap the cables.
I would strongly suggest puting a ICSP header in the next version of the UCB also.

I live in the Houston, TX area and I know there are other around here. There is even a user group of us. I think I might be further ahead though. Jim (aka Cheap!) was having problems with software and I don't know if he's gotten as far as programming and electronics yet. He's building the axis'. I'll check with him and see if he has the parts yet, maybe I got a bad batch or something.
Did the problem with Kai ever get fixed?

Dylan wrote:

> I live in the Houston, TX area and I know there
> are other around here. There is even a user group
> of us. I think I might be further ahead though...

OK. Mail from here (Southern California) to Texas is
cheap, so if necessary I could mail you a test PIC.

> Did the problem with Kai ever get fixed?

Not that I know of; I suspect he gave up? Kai, if
you are reading this, let us know the current status!

Jonathan

---

---

Jonathan

Would be easiest to take it all to college and find someone who knows how to use a scope it's not difficult just easier if someone is sat next to you, as i said before i think it an unlikely option it's just if you've tried everything else and it sounds like you have then you have to hunt deeper!

Borrowing a PIC is a very good option, and will be easier then the college option I'm sure

---

Ian
[www.bitsfrombytes.com]

Thanks Jonathan I might have to take you up on that offer, I could probably give you a few $ on paypal to cover shipping.

I tried installing SDCC and making the tx_baud file from the source and then simplify it to get it to just send 1 character that I actually can receive without junk. Unfortunately it gives me an error when trying to open the pic14.h file. I put it in the include folder and now it sees it, but I still get an error (plus a bunch of undefined variables and stuff).

Dylan