I have hit dead end, and I don't have enough ideas on how to continue :)
I have soldered the kit that i have received.
Programed PIC with bootloader using pickit2.
Programed main FW using fw-update.
Programed AT dataflash with FPGA_ROM (i tried multiple)
After i plug in the pump, it blinks several times (6-7-8), and then the LED turns off (?).
According to the firmware main.c, the led whould be on unless in UPDATE mode. But it's not. I cannot talk to the PUMP using pump-loader. I have also tried terminal, and send some characters over (0x00 - reset, and 0x02 - ID) - didn't work.
I have also reheated every single pin on ICs, just to be sure there is no cold joint.
Any ideas ?
UPDATE: Main firmware seems to work. While sending large chunks of data, the led blinks. So it could be something with the FPGA chip ?
UPDATE2: Even the RX/TX connection seems to be soldered ok. Could it be the FPGA broken ?
robots,
Is the Xilinx FPGA chip oriented correctly? The smaller circle should be in the upper right hand corner next to the pin 1 marking. This means that the word "Xilinx" is upside down.
What firmware files are you using? We recently made a change to the hex file and the FPGA firmware that moves the serial pins off the TRGO line.
Now that I think about it this is most likely your problem. Make sure that the PIC firmware you are using is the latest version from svn (http://gadgetforge.gadgetfactory.net/gf ... x&view=log (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FFirmware%2FPUMP.hex&view=log)).
And the FPGA bitstream is one of the latest. (http://gadgetforge.gadgetfactory.net/gf ... M%2F2.0%2F (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2Fpackage%2FFPGA_ROM%2F2.0%2F))
Most likely what is happening is that the latest change from svn did not make it into the package file for the PIC firmware but did make it for the FPGA bitstream. I'll check and update as soon as possible. In the meantime get the latest files from svn.
Jack.
Ok,
New release of the package with the latest PIC firmware that should match the latest bitstreams is available for download at the file repository (http://http://www.gadgetfactory.net/gf/project/butterflylogic/frs/?action=FrsReleaseBrowse&frs_package_id=12) now.
I have soldered the board according to picture posted here on the forum.
I have uploaded new firmware, but still no communication. Ill have a look at it tomorrow with a scope or something.
My suggestion was going to be the same as Jack's - we moved the RX/TX pins around a bit and maybe your PIC firmware and FPGA bitstream aren't talking on the same pins.
You can connect the Bus Pirate to the PIC pins and use two terminals to see if you can send data back and forth between the PUMP to the Bus Pirate.
Could you send me Pic fw and FPGA bitstream that you used in your test ?
Im going to try the BP on TX RX pins.
Remember to check the schematic and tap into the actual PIC->FPGA pins. The serial header on the board is for external serial control as an unimplemented alternative to USB, not a tap into the PIC->FPGA part. I'll try to find the post with my last know working firmware combo.
This isn't the latest, but this is a 'known working' package will all the parts:
http://whereisian.com/forum/index.php?t ... 49#msg2549 (http://whereisian.com/forum/index.php?topic=270.msg2549#msg2549)
Ok, so there is data going from pic to fpga on pin 22. And data coming back from FPGA is on pin 23 of PIC.
It seems that there is a problem with the PIC firmware not receiving the data correctly.
You're using the firmware and matching bitstream from the linked archive? I think there is probably a segment of the tool chain with the wrong output/input pins. The package at the link should have some signal on pin 23 of the PIC because we accidentally started out with the TRIG_O pin and RX (or TX) on the same pin. One of the more recent packages moved one of the pins. If you're using firmware from the above archive, try erasing the ROM and uploading the bitstream from the package to see if it moves a signal to pin 23.
Post 996, almost to 1000 :)
are you sure that the firmware HEX in SVN is the one that has RX on pin 23 ?
I see that is has been changed in main.c, but i guess that the hex is not correctly uploaded. I have just finished installing C18 compiler, i'm going to recompile it.
The package from 8th feb 2010 works :)
I guess that the new PIC firmware has a bug.
Glad you got it working, looks like there is some sorting out to do with the package files still.
Looks like the look and feel of the forum has been upgraded, I like it.
Jack.
Thanks, they deprecated our old theme so I had no choice but to change. I enabled custom themes, so you can go into your user profile and try different themes too.
How do I buy one of these to try?
I have all the expertise and equipment to solder almost anything under the sun.
I have hot air iron, programmers to program pics and even a logic port logic analyzer to compare to this. I hope in the future, we can expand the memory depth and put in other features that would make this my first choice of logic analyzer!
Cheers!
Hey goldserve - I'm glad you're excited, it would be great to have more help kicking together the next version. Version 1 should go on sale really soon. Hardware will be assembled already, but it's open source so you can still have your own boards made and build one yourself if you're after the soldering fun.
I still have not resolved this issue :(
Does the release and preview board differ (connection wise) ?
Was the OLS-v1.01 package tested successfully on preview board ?
There is also some trouble with the "analyzer.jar" not working correctly on Linux, recompiling from CVS helps.
Fw_update does not work on linux. I'm working on patch, to make it more user friendly.
The release and preview board are identical except the silkscreen.
I've been buried in the article for the last few days. Now that it's done, I should have time for the fun stuff again :) I'll recompile everything tomorrow and test it again. Jack mentioned that there might be a UART bug in some of the builds, but the 32channel/4K version is working (as I recall). We'll prepare a new release with known-working everything soon. Jack mentioned that if the UART is giving us troubles, it might make more sense to just implement the high speed SPI interface now, which would be a fun project.
I would join the party with SPI, but i have almost no time these days :(
I have created (and attached) patch for fw_update, that makes it work with linux.
The bootloader is behaving strangely. When second command is issued, sending the data fails. I have to wait for about 0.5sec before sending another command.
(ERASE<-0.5sec->WRITE<-0.5sec->RESET).
Also, reset command fails on the host side, PIC resets ok. I assume that PIC resets before it can even reply to the host, and Win32 ignores this, and in linux it is error.
@robots
I just uploaded a new package file that has all the different memory configurations and the new uart locations. All FPGA_ROM's work on both my boards, if you want to give them a try they should work for you now.
http://gadgetforge.gadgetfactory.net/gf ... ase_id=119 (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/frs/?action=FrsReleaseView&release_id=119)
They work great :)
About the linux version of analyzer.jar. I had to recompile for some reason, all the "Device" options were grayed out. Also RXTX does not handle ttyACMx well (at least it didn't show up for me). I'm using this command line to fix the problem:
java -cp /usr/share/rxtx-2/lib/RXTXcomm.jar:./analyzer.jar -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM0" -Djava.library.path="/usr/lib/rxtx-2/" org.sump.analyzer.Loader
-cp tells java, where to look for class files (RXTX and sump)
With gnu.io.rxtx.SerialPorts you can tell RXTX which ports are available (instead of probing).
java.library.path tells java where to look for JNI .so libraries. The path provided is valid for Gentoo.
Just change the paths to RXTX .jar, and .so files and it should work :)
@robots
Good to know for Gentoo, one of us might want to start a Linux section on the project wiki page for tips like this. (http://gadgetforge.gadgetfactory.net/gf ... ogic/wiki/ (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/wiki/))
Everything worked fine with just loading the packages under Ubuntu but each Linux distro is going to have their own way of doing things. I love Linux but all of the different distro's makes it hard to make a universal installer/package. Maybe we can make packages for the major distros like RedHat, Debian/Ubuntu, and Gentoo. Sounds like you already have the Gentoo specifics figured out.
You could just add the RXTX lib to the package with the analyzer.jar. That way you wouldn't have to deal with (possible) future version incompatibilities, and it would be working on all systems that have JRE. Probably save a lot of time, by not having to download the included JRE package.
Could you please test the RLE ? There seems to be too much noise on every channel for every ROM with <32bits. Could be some floating "pins" inside the FPGA logic ?