Skip to main content ↑ ↓
Topic: 1.03 "16 channel, 8k samples, inside" firmware is broken (Read 3999 times) previous topic - next topic

1.03 "16 channel, 8k samples, inside" firmware is broken

After loading up the 1.03 16ch/8k/inside firmware the OBLS stopped working, the symptom being that Sump said it couldn't find the device.  I assumed that meant the PIC firmware was somehow hosed, but looking at the design info shows that in normal mode the PIC just acts as a USB passthrough to the FPGA, so it's not the PIC firmware that's bad, it's the FPGA firmware.  I loaded up the 8ch/16k/inside firmware and that seems to work fine.

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #1 –
Spoke too soon - it worked for a bit, then disappeared again when I pressed reset on the board, the only solution was a reboot.  This is potentially a wonderful kit of kit, but at present it's just way too flaky to be practically useful.  Do SparkFun have a returns process, and if so what's the timeout on activating it?

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #2 –
And RLE mode doesn't appear to work properly either...

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #3 –
[quote author="alanbur"]
Spoke too soon - it worked for a bit, then disappeared again when I pressed reset on the board, the only solution was a reboot.  This is potentially a wonderful kit of kit, but at present it's just way too flaky to be practically useful.
[/quote]
Everbody has been warned (by the Seedstudio shop at least):
Quote
The ordering page for the Sniffer carries this note:
This open source hardware and software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If you can't accept this risk, please do not buy this hardware.
I expected this to be a rough ride so I'm quite surprised it worked right away with the on board 32channel bitstream.

Apart from that the OpenBenchSniffer works (at least  partially) here on Ubuntu, which makes it currently the only choice on Linux from what I know.

I rather monitor the svn-repository for this project for half a year, than wait for the SaleaeLogic VaporwareForLinux to be officially dumped someday. 

Quote
  Do SparkFun have a returns process, and if so what's the timeout on activating it?
Sparkfun???

Eberhard

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #4 –
Hello,

I'm very sorry that it has been a rough ride so far. I just tested the "16 channel, 8k samples, inside" 1.03 bitstream on my OLS and it actually works. Everything works on my development board but as can sometimes be expected we are seeing differences when several boards are manufactured.

We have been seeing issues with the communications between the PIC and the FPGA, so most likely what you are seeing is that with the bitstream you are using the timing between the PIC and the microcontroller is off so the serial communications fails. We are working on integrating a synchronous SPI module for the communication channel between the PIC and the FPGA. We really expect that this will clear up these types of issues and will work in all cases on all boards.

The other issue that we are working towards a solution for is the RLE issue that was mentioned. Right now the RLE only works with the 32 channel bitstreams, the RLE uses the 32nd channel to store its marker. In the other bitstreams there is no 32nd channel so RLE goes haywire. The SPI module is the priority but after that we will be finishing up a new single bitstream for all of the memory configurations. The goal is to not require loading different bitstreams for different memory depths. Finally we will change things around so the RLE uses parity instead of the 32nd channel, this will enable the RLE to work in any mode. Please be patient with us while we work on these fixes, it is my highest priority right now but it is taking some time.

I certainly don't blame you if you want to return the board, but if you hold on for a while I think things will be much better.

Thanks,
Jack.

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #5 –
Quote
The ordering page for the Sniffer carries this note:
This open source hardware and software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If you can't accept this risk, please do not buy this hardware.

They can put whatever they like on their web page, that doesn't trump the law.

Quote
Quote
Do SparkFun have a returns process, and if so what's the timeout on activating it?
Sparkfun???

Oops - seeedstudio of course ;-)

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #6 –
[quote author="alanbur"]
Spoke too soon - it worked for a bit, then disappeared again when I pressed reset on the board, the only solution was a reboot.  This is potentially a wonderful kit of kit, but at present it's just way too flaky to be practically useful.  Do SparkFun have a returns process, and if so what's the timeout on activating it?
[/quote]

That's pretty much my experience with trying various versions of the FPGA firmware, some power ups it works, some it doesn't.

Since we were pre-ordering the first version of the board I didn't expect flawless performance.  Almost anything you can get the prototype working well, it's not until the production version hits the street that you have enough in use to find some problems.  I expect that it will take a few revisions of the firmware to get everything working on all the boards.  Maybe even a minor hardware revision or two (blue wire jumpers or an added cap or two) to get all our boards working properly.  With a little patience we'll all end up with a great little logic analyzer for less than $50.

-Hank

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #7 –
[quote author="alanbur"]
They can put whatever they like on their web page, that doesn't trump the law.
[/quote]
Seeed is in Hong Kong, China.   US law doesn't apply.  When we order from overseas we accept that the local law wherever the seller is applies.

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #8 –
[quote author="jack.gassett"]
I certainly don't blame you if you want to return the board, but if you hold on for a while I think things will be much better.
[/quote]

The timing issue you describe certainly explains the symptoms I'm seeing (and other people's similar issues too), and the RLE explanation makes perfect sense as well.  I'm happy to wait for fixes if they are coming, my concern was that I had a board that was either defective or that wasn't ever going to work, in which case I'd have to have returned it within whatever period Seedstudio allow for DOA kit.

The problem that I'm having (and I suspect others are too) is that without information on the current limitations it is impossible to know if the issue is a broken board or not.  It would be an enormous help if someone could post a 'Here are the bits that currently do/don't work' summary on the forum, make it sticky and keep it up to date - that would be an immense help :-)

Re: WARNING: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #9 –
Sure, but if the board is DOA you'd still be entitled to a return or replacement, Seeed are a reputable company, and they have a Warranty policy for faulty goods.  As I've said, it wasn't clear if the issues people have been seeing were because of defective hardware or just the alpha nature of the software.

Re: [SOLVED] 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #10 –
Quote
The problem that I'm having (and I suspect others are too) is that without information on the current limitations it is impossible to know if the issue is a broken board or not.  It would be an enormous help if someone could post a 'Here are the bits that currently do/don't work' summary on the forum, make it sticky and keep it up to date - that would be an immense help :-)

At the moment the problems are just now arising (because people are getting the hardware) and the issues are inconsistent between boards (with the exception of RLE). We'll post a failure analysis soon.

I think a lot of the intermittent errors are related to SUMP timeout waiting for a byte from the USB->serial converter. I posted a possible explanation and solution here:
http://dangerousprototypes.com/forum/in ... opic=549.0

I have a board in front of me that just does not respond when certain bitstreams are installed (the issue listed here). My prototype works fine with them, but when installed on this board it doesn't work. Serial COM from PIC to FPGA looks fine on a logic capture, but the FPGA never responds. I'm working on debugging this board now.
Got a question? Please ask in the forum for the fastest answers.

Re: 1.03 "16 channel, 8k samples, inside" firmware is broken

Reply #11 –
OK, I've done some more testing:

1.03, Windows XP, 19200bps, 2 runs through each of the the FPGA firmware load processes

4k32bit_inside - worked both runs
4k32bit_outside - worked 1st run, didn't work 2nd run, powered off then worked on 3rd capture
8k16bit_inside - didn't work at all
8k16bit_outside - didn't work at all on 1st run, worked 2nd run on 4th capture
16k8bit_inside - worked 1st run after about 6 captures, didn't work at all 2nd run
16k8bit_outside - worked both runs

1.02, Windows XP, 19200bps, 2 passes through the FPGA firmware load process

4k32bit_inside - 1st run worked 3rd time after power on/off,  2ns run worked 2nd time after power on/off
4k32bit_outside - worked both runs
8k16bit_inside - didn't work at all
8k16bit_outside - 1st run worked 3rd attempt, 2nd run worked 2nd attempt
16k8bit_inside - didn't work at all 1st run, 2nd run worked 2nd attempt after power off/on
16k8bit_outside - worked 1st run after 2nd capture, 2nd run worked 1st time

All FPGS firmware uploads worked fine.

Observations

1. If it was a hardware comms issue issue I'd expect the FPGA uploads to fail as well, they didn't fail even once

2. The 8k/16bit/inside firmware doesn't work at all, the others are slightly better

3. If it was purely a timing problem I'd expect to get intermittent issues on each capture.  However once you get one capture working, all the subsequent captures seem to work fine.  That might suggest an initialisationproblem rather than a purely comms problem