For information, it’s the same in mine.
I also get a 005 Waiting for keyboard idle message when I first turn it on.
After I release the third button I get the 011 Enabling capture TIM1 priority message.
I’m using SYS_B151.HEX from here (and it works for me): <LINK_TEXT text=“http://www.seeedstudio.com/forum/downlo … php?id=857”>http://www.seeedstudio.com/forum/download/file.php?id=857</LINK_TEXT>
Here are a few new programs you can try to get more information:
- Testing the screen drawing when signal capture is disabled. This skips the capture start, which seems to be where it crashes. Just verify that the screen draws correctly (albeit slowly, due to debug messages):
http://kapsi.fi/~jpa/stuff/other/LOGIC001.HEX
- Printing a message when first interrupt routine completes, and stop. This tells if the proper interrupt is even running, and if it is, whether it completes:
http://kapsi.fi/~jpa/stuff/other/LOGIC002.HEX
- Initiating a crash dump after 10 seconds. This should draw the screen red after 10 seconds and print some debug data. A photo of the red screen would be most useful; you can also post the memory.dmp from the USB drive if it manages to write one. I had to change some interrupt priorities to make the dump work, so please verify that it still hangs in the “Enabling capture TIM1” during the first 10 seconds.
http://kapsi.fi/~jpa/stuff/other/LOGIC003.HEX
1) Please see video here (sorry, I don’t have time to record it better/crop/recompress…) <LINK_TEXT text=“http://ajpiny.aitcom.cz:55555/owncloud/ … 45593109f5”>http://ajpiny.aitcom.cz:55555/owncloud/apps/files_sharing/get.php?token=c1b0678b3237696485a8b1e906c88a45593109f5</LINK_TEXT>
2) Ends with 011 Enabling capture TIM1 priority, no other messages
3) Also ends with 011 Enabling capture TIM1 priority, no red screen after 10s (and longer) and no memory.dmp
1) works like it does for me.
2) and 3) are quite surprising results. Apparently the correct IRQ doesn’t run at all or it crashes hard.
Here is another try. It has a more foolproof crash logic, I noticed that I had forgotten some bad old error handlers in the code:
http://kapsi.fi/~jpa/stuff/other/LOGIC004.HEX
Observe in particular if there are any red pixels in the upper part of the screen - they are an indication that the IRQ is running.
Thanks for helping out with the testing 
Oh: by the way, also try with the usb cable disconnected! Maybe the USB interrupts are causing some distruption.
Logic004:
ends on 011 Enabling capture TIM1 (chip rev 411fc231)
no red dots, same behavior with and without USB connected
Keep the tests going, you will figure it out eventually 
I still find it strange that it works for you (and other people) but doesn’t work for me (and other people)…from your previous post I see that we are using same SYS version, identical HW probably, could FPGA code mean any difference for your APP? Could it be somehow influenced by some settings in Quads main App? Any other ideas?
Based on the tests, I have traced it down to that something crazy happens as soon as I enable the TIM1 timer. I’m using it to drive the DMA that transfers data from FPGA to memory. Right before I enable the timer, I write the text “Enabling capture TIM1” - and as soon as I get the DMA interrupt, I draw a bunch of red pixels. I really don’t have a good theory where on earth it magically jumps in the between, because obviously it does not execute the main program but it doesn’t execute the interrupt routine either.
Here is a yet another version. This time the HardFault handler can survive a corrupted stack pointer. I’m hoping so much that it would just give the red screen 
Almost like using Windows, hoping all the time to see the blue screen, right?
http://kapsi.fi/~jpa/stuff/other/LOGIC005.HEX
And regarding the differences; I realized that we may have different bootloader versions because it is not upgradable through USB. Mine is “Device Firmware Update V3.10”. Using this application (APP3 slot) you can dump your whole flash to flash.bin. Then I can load the file to my device using the programming port on the PCB and then our devices should be exactly identical by code:
http://kapsi.fi/~jpa/stuff/other/BOOT_APP.HEX
A quite probable theory is that we have different revisions of the STM32F103VCT6 processor. Unfortunately, one of the bugs in that processor is that it is impossible to read processor revision (DBGMCU->IDCODE) by software!
Hi, keeping in mind that I run Ubuntu (linux),
with LOGIC005.HEX in slot 3:
I am unable to mount the device in order to get the dump file. I get the following error:
[56530.220654] sd 17:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 20 00 00 20 00
[56530.220666] end_request: I/O error, dev sdd, sector 32
[56530.220672] quiet_error: 36 callbacks suppressed
[56530.220676] Buffer I/O error on device sdd, logical block 4
[56530.220686] Buffer I/O error on device sdd, logical block 5
[56530.220690] Buffer I/O error on device sdd, logical block 6
[56530.220694] Buffer I/O error on device sdd, logical block 7
etc, etc, etc…
Using slot 1, I am able to mount the device, but no dump file
Also using slot 4 (Frequency response for DSO Quad) I am able to mount the device, but no dump file.
LOGIC005.HEX looks just like LOGIC004…HEX
Ok, yeah, if it doesn’t show the red screen there is not going to be any dump file either.
However the other app (BOOT_APP.HEX) should create a file called flash.bin.
Just knew I was forgetting something
Just confirming mrtaylor:
LOGIC005.HEX - no red screen, same output as LOGIC004
As for bootloader, mine is also Device Firmware Upgrade V3.10. Checksum after BOOT_APP.HEX is 6715, flash.bin is generated but I’m not able to copy it to PC (Windows) - maybe I’m doing something wrong.
Freshman: I don’t use windows, but to access the flash.bin file just plug in the usb cable and turn on the quad with no buttons pressed. A new window should open and you should be able to access the flash.bin file just like you would with the screen dump files.
mrtaylor: then I was doing it right, I am able to make screenshot in APP1 and copy it to PC from DSO “flashdrive”, I can also see “flash.bin” (262144 B) there, but unlike screenshots I am not able to copy it or delete it…
I flashed mrtaylor’s flash.bin to my device - and it still works perfectly fine! I guess there must be some very well hidden hardware difference in our devices, maybe in the processor itself.
One way would be to open the backcase and read the revision number written on the processor. But opening the device is probably too much work/risk.
I guess I’ll just keep reading the errata documents, maybe something will pop up.
By the way: if people could list the date they bought their device and whether the logic analyzer app works for them, it would help. Freshman already told that he bought his in May 2011, and he has the bug. I bought mine in October 2011, and I don’t have the bug.
Hello
I bought my DSO203 on eBay in December 2011. The logic analyzer works well on it.
Patrick
Yet another try:
http://kapsi.fi/~jpa/stuff/other/LOGICAPP.HEX
This time I have a pretty strong theory about what went wrong. The STM32F103 processor revisions before ‘Y’ have a bug, where accessing the external memory bus from 2 places at once may crash the processor. Because the LCD and the FPGA are on the same bus, I did exactly this: writing to LCD from DMA2 and reading FPGA using DMA1. I now moved the LCD code to use DMA1 also, which should fix the bug at the cost of slowing down screen update a bit.
Edit: I made a small additional change to the file just now.
Still not working for me 
Only splashscreen
Try again
http://kapsi.fi/~jpa/stuff/other/LOGICAPP.HEX
But this is a very very nasty CPU bug. The original firmware manages to avoid it only by doing things in a quite inefficient way. In fact, there are some signs of them trying to use DMA at first, but I guess they had to give up because it is buggy.
!!!IT WORKS!!!
(or at least I can see interface of your app) :lol:
EDIT: and IT WORKS (like I have captured something and tried to navigate around and it is alive)
EDIT2: and I don’t know if it is of any help now when you found what is the problem, but I have disassembled my unit:
<LINK_TEXT text=“http://ajpiny.aitcom.cz:55555/owncloud/ … 8f1052ac31”>http://ajpiny.aitcom.cz:55555/owncloud/apps/files_sharing/get.php?token=e5c19d9404500fe45198f2cc8b7c868f1052ac31</LINK_TEXT>
<LINK_TEXT text=“http://ajpiny.aitcom.cz:55555/owncloud/ … 3a16b5498f”>http://ajpiny.aitcom.cz:55555/owncloud/apps/files_sharing/get.php?token=340dfc85c8c6fd4773ce98adbac9ca3a16b5498f</LINK_TEXT>
The original HEX http://essentialscrap.com/dsoquad/LOGICAPP.HEX works on my DSO203 too (shipped in January 2012)
I suppose new boards ship with the fixed MCU…