DSO Quad Logic analyzer application

Sure. Someone just needs to program that :slight_smile:


But who would have helped with that, I don `t know this programming language. away mou only offer testing and the concept of signal processing

I feel a bit silly for this but… I can’t figure out how to use the app. I’m trying to use it to debug an SD card library that I’m writing but nothing I do affects the signals being displayed. I can use the -/+ adjustment to zoom in and out, but moving the probe connected to Channel A from ground to Vcc (3.3V) and back to ground again does nothing.



Thanks,

David



–EDIT–

FOUND IT! Turns out, it doesn’t work so well in x10 mode. I should have known that… :confused:

Also, now that I’m using this… wow. Just… wow. This app is AMAZING. I can’t believe I have this kind of functionality AND an oscilloscope for $200 USD. The memory effeciency of your app is excellent - I love how sitting idle watching lines not change doesn’t take up any memory, therefore no triggers are needed. Just record it all! BRILLIANT!

Thanks :smiley:

Further use has shown a bug. I believe it’s related to high-frequencies. I’ve taken a snapshot of the memory dump for you:





While attempting to debug a MAX3232 chip (coms were running at 9600 baud), I was getting a very high-frequency signal. I’ll ignore the “Why?” and just say, something was wrong. While reading this signal (I believe it was approaching the MHz range if not surpassing) it would periodicaly die and produce the above memory dump (as opposed to freezing and me forcing it to do a memory dump).



Let me know if there’s more information I can provide.



David

Upon reading the “oh noes” at the top, it looks like the ADC FIFO can’t be read fast enough, which would make sense since the signal was so fast. Would a better approach be to send a warning message to the user “Warning: ADC FIFO has overflowed. Output may not be accurate”, rather than forcing a restart?



If this was your plan but you haven’t had time to implement it, I might be willing to help you out with that. I have a bit of experience with TI’s LM4F series of M4 chips, so I ought to be able to help out some with an M3.

Yeah, that is correct. The way the signal capture is implemented now is a very big hack, because at the time the FPGA tools were not available.

My real plan is to implement the capture on the FPGA side.



In fact, I already have a FPGA image capable of doing this, and also a test program:

<LINK_TEXT text=“https://github.com/PetteriAimonen/QuadP … /LOGIC.FPG”>https://github.com/PetteriAimonen/QuadPawn/blob/master/Programs/LOGIC.FPG</LINK_TEXT>

<LINK_TEXT text=“https://github.com/PetteriAimonen/QuadP … iccap.pawn”>https://github.com/PetteriAimonen/QuadPawn/blob/master/Programs/logiccap.pawn</LINK_TEXT>



It should be pretty simple to integrate it. Just need to copy over some of the FPGA access code from QuadPawn and replace the signal capture part in the logic analyzer (it’s currently in main.cc). It should allow overflow-free capture up to the 4096 sample FIFO, including RLE encoding.



So why haven’t I integrated it yet? Two reasons: no time, and I have something even better in the works. The FPGA should be able to also further compress the data, which would increase the capacity and speed up display drawing. However, it is difficult… :stuck_out_tongue:



If you can help with integrating the current version of FPGA capture, it would be very useful.

Hi jpa…



First another round of thanks for your excellent work on the DSO - I too have found your Logic Analyser a handy tool.



But on to the point… I’ve been trying to build on your fpga and pawn extensions and am finding that decreasing the sample-rate leads to overflow of the sample buffer - rather the opposite of my guess!



I wonder if you could give some indication of what’s happening in the fpga mod?



Cheers!

The block is meant to only work at 72 MHz. This is because I want to use the memory bus synchronously (it’s easier to design and to debug). This means that because the CPU always runs its memory bus at 72 MHz, the FPGA also has to run at 72 MHz. Because of the RLE coding, the samplerate should not be that important - but it could still be divided on the FPGA side if necessary.



The VHDL code is here, btw:

<LINK_TEXT text=“https://github.com/PetteriAimonen/dso-q … pport/fpga”>https://github.com/PetteriAimonen/dso-quad-logic/tree/fpga_support/fpga</LINK_TEXT>

Brilliantly generous - time to scrape the rust off my verilog and get stuck in!

Better scrape off your VHDL also unless you want to start from stratch :slight_smile:



The verilog code from seeed is quite crappy, I wouldn’t base anything off it.

I’m finding that when two channels have an edge at the same time, I’m only getting one edge reported in the recv buffer ( first two channels hung on a single line).



I suspect this might be something to do with the edge-matcher VHDL but can’t quite see what’s wrong… Will keep digging but wondered if anyone had seen/solved this already? Or have you found this perfectly fine and I need to dig deeper into the software handling?

Hmm, so you are seeing:



1000 A0 B0 C0 D0

1001 A1 B1 C0 C0



Isn’t that exactly what should happen, the signals change at the same time => they are reported on the same line?

Hello,

has anyone tried the LogicAnalyzer on DSO Quad HW2.72 ??



thx

Yes. It loads and seems to run but crashes if you try and save anything.



Hopefully the author will release an update :slight_smile:

Hello,



The reason causing problems with HW 2.72 is increase flash memory up to 8MB. This change caused a change the FAT sector size of 512 to 4096 bytes.

The read/write BIOS functions read/write one full sector, so buffer used in application must have a size of one FAT sector.

In logic analyzer application in file ds203_io.c buffer is declared:
</s><i> </i>// Err.. something somewhere is writing past SecBuff, and I'm quite sure it is // not my code. Allocating a bit more than 512 bytes for that purpose. static u8 SecBuff[600]; <e>
For the application to work correctly with the new HW is a need to change the buffer size to the new sector size and correct fixed size of 512 in the functions _fputc() and _fclose() to the actual system sector size.

Logic analyzer after that change correctly saves both types of files :smiley:



But … after this change, we have another problem :frowning: - in the current version we have ~4 KB for captured data. When the FAT I/O buffer will be increased, then we lose the additional RAM space and for data capture will be less than 500 bytes.

Which means that the application requires a thorough rebuild :cry:





Best regards,

Robert

Actually, the default space for signal capture stuff is 25kB in dsosignalstream.hh. The 4kB is just for malloc()… 500 bytes is probably a little bit too little for that though.



(I’ll tell you a secret: there is 16 kB extra ram on DSO Quad. Maybe use that?)



But anyway, better to use AlterBIOS like QuadPawn does.



Btw, if you want long captures, use vcd capture application in QuadPawn. It captures at 72 MSps to flash drive.

Hi,



Thanks for the information.

Decrease signal capture buffer in dsosignalstream.hh solved problem with RAM memory for malloc :smiley:



ALTERBIOS (binary version 0.4) incorrecty works on HW 2.72. After AlterBIOS hex file is loaded, flash disk is not properly accessible (already at start we have information: “AlterBIOS 0.4: FatFS fail”). In sources I saw that AlterBIOS is built using SYS_B152.HEX. HW 2.72 must have loaded new SYS version min. 1.60 (on MiniDSO.com site I found latest version SYS_B161.hex). I think that’s why the last version AlterBIOS 0.4 doesn’t work properly with HW 2.72.



Are you planning to develop Logic Analyzer application yet? GUI created by you to display captured signals is really awesome, but of course it still needs a little fine-tuning (already by yourself I made some changes and corrections :slight_smile: ).





I also have an additional question: Do you know why HEX of your applications (AlterBIOS and PAWN) have problems with normal loading to the device? The disk is removed before the operating system finishes copying file and we get message copy file error. But … loaded applications seems to be working correctly.





Best regards,

Robert

I think the problem loading the Hex is down to a problem with the basic Hex loader which doesn’t seem to like short or overlapping hex records. The build for Alterbios and Pawn seem to prodcue a couple of instances of these probably as segment changes are made. My theory is that the buffer used to hold the hex data is not cleared out properly prior to each record but I have never managed to find the source for the base DFU to verify and or correct any problems in this area. I have successfully loaded problematic Hex files by manually combining the couple of short records that can occur in Pawn / Alterbios. I would not rely on apps where it doesn’t complete loading successfully as part of the file near the end may not have flashed properly.



On the version of which SYS is used the main difference between the one for the 2.72 and earlier versions is the support for 8MB flash, but ALTERBIOS replaces these routines anyway so it should not matter which you start from.