Thanks 
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ā>QuadPawn/Programs/LOGIC.FPG at master Ā· PetteriAimonen/QuadPawn Ā· GitHub</LINK_TEXT>
<LINK_TEXT text=āhttps://github.com/PetteriAimonen/QuadP ā¦ iccap.pawnā>QuadPawn/Programs/logiccap.pawn at master Ā· PetteriAimonen/QuadPawn Ā· GitHub</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ā¦ 
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ā>dso-quad-logic/fpga at fpga_support Ā· PetteriAimonen/dso-quad-logic Ā· GitHub</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 
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 
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 
But ā¦ after this change, we have another problem 
- 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 
ā
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
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 ).
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.