While I am waiting for delivery of my OLS, since I had a need for it, I wrote this parallel trigger (and complete SUMP service) to ultimately replace the triggerless Bus Pirate Logic Analyzer mode.
I don't have the PIC development environment installed, but I do have AVR, so this code has been tested on AVR only. Note that the sample clock mechanism is undeveloped, but is timer polled-ready, so I figure a PIC-savvy developer could easily plop it in.
As far as the maximum sample rate, I got about 5kHz at 20 MIPS on the AVR, which is OK if you can slow your target process (e.g. communications bit rate, hardware I/O) down to suit the slow sample rate.
I know the sample rate is excruciatingly slow, but when you need a trigger, you need a trigger (That's why I ordered an OLS).
The trigger stages operate in sequence, not random access.
I was able to get this working with the SUMP client at http://gadgetforge.gadgetfactory.net/gf ... ase_id=128 (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/frs/?action=FrsReleaseView&release_id=128).
Unfortunately, I was unsuccessful getting this service working with the http://www.lxtreme.nl/ols/ols-0.9.2.tar.gz (http://www.lxtreme.nl/ols/ols-0.9.2.tar.gz) client, which is the "preferred" OLS client. The symptoms were that the client didn't seem to see the service's transmissions.
I hope someone can port this to the Bus Pirate and get it working with the "preferred" OLS client.
Thanks.
Walt.
Hi Walt
This is fantastic, thank you. I'll take a look at it tomorrow.
We should work together with Jawi to figure out why it doesn't like the Bus Pirate.
Hi Ian,
I did not mean to imply that the code would not work on the Bus Pirate, on which I have not tried it yet; I just had differing low-level serial I/O results between the two clients I tried with my AVR target and Prolific serial port driver.
I developed the triggered logic analyzer service on an AVR because it was a more convenient platform for me. Although the code is "99%" portable to the PIC/compiler, so far I have been too lazy to merge it with, and build the Bus Pirate code.
Walt.
Unfortunately, I was unsuccessful getting this service working with the http://www.lxtreme.nl/ols/ols-0.9.2.tar.gz (http://www.lxtreme.nl/ols/ols-0.9.2.tar.gz) client, which is the "preferred" OLS client. The symptoms were that the client didn't seem to see the service's transmissions.
Sorry for the confusion, I meant this part. I think the Bus Pirate has the same issue, it doesn't work with the newer client for some reason.
@ian or flubberlab: could you provide me some details on what is not working? Does it abort the capture stating it cannot find the device, or doesn't it do anything, or ...?
I've got a BPv2go at home which communicates with the current software, though I should probably test it more often...
I should probably test it too :) Sjaak and some users have mentioned issues in the past. I believe when I had the issues with a development version (prior to you working on it) it started to dump data, but the client would time out before the next USB packet arrived. On portmon you could see that there was data, but the client was timing out. I think you made it more robust to that already. The .8.x (the original version that is floating around) always seemed to work, but the various SVN compiles (like the Gadget Factory SVN version) had the timeout issue.
Here's a test I performed with the AVR-based service and client v0.9.2.
Rather than Portmon, I used both of my Bus Pirates (and terminal programs) to monitor serial traffic at the service target. I was experiencing crashes of the client, and wanted to see actual hardware signals in case there was some weird software interaction.
Test Configuration:
AVR-based service (published SumpCap.c code) plus Tx extra 00 for Protocol Version response (Bus Pirate v5.10 bug?) and guaranteed data return (Run procedure bypassed); Prolific USB-serial dongle + driver; SUMP client 0.9.2; WinXP Pro
Test Procedure and Results:
1. Start client
2. Press Capture
3. Client Tx: 00 00 00 00 00 02 04
4. Service Tx: 31 41 4C 53 01 42 50 76 33 00 21 00 00 04 00 23 00 01 86 A0 40 08 41 02 00 [same results with or without this extra 00]
5. Client status: "Capture from Open..."
6. Close client
7. Client Tx: C0 80 00 00 00 C1 00 00 00 00 C2 00 00 00 08 C4 00 00 00 00 C5 00 00 00 00 C6 00 00
03 00 C8 00 00 00 00 C9 00 00 00 00 CA 00 00 03 00 CC 00 00 00 00 CD 00 00 00 00 CE 00 00 03 00
80 63 00 00 00 81 FF 00 C4 00 82 38 00 00 00 01
8. Service Tx: 1024 bytes of data
9. Start client
10. Press Capture
11. Client Tx: 00 00 00 00 00 02 00 00 00 00 00 02 00 00 00 00 00 02 00 00 00 00 00 02 00 00 00 00 00
12. Service Tx: 31 41 4C 53 31 41 4C 53 31 41 4C 53 31 41 4C 53
13. Client status: "Capture aborted! Device not found!"
14. Close client
15. Client Tx: none
16. Service Tx: none
17. Repeat Steps 9 through 16 as many times as you want: Same results
18. Unplug service serial port (uninstall)
19. Plug in service serial port (install)
20. Repeat Steps 1 through 19 as many times as you want: Same results
Analysis:
Judging from these observations alone (I have not looked at the client source code), to me it looks like the client (or serial driver) may be buffering the data from (and to, perhaps) the service port, and not seeing it. I think the results in Step 7 support this idea. When the client is closed, it looks like the I/O buffers, at least the input, are flushed, revealing the remainder of the expected commands.
[quote author="ian"]I should probably test it too :) Sjaak and some users have mentioned issues in the past. I believe when I had the issues with a development version (prior to you working on it) it started to dump data, but the client would time out before the next USB packet arrived. On portmon you could see that there was data, but the client was timing out. I think you made it more robust to that already. The .8.x (the original version that is floating around) always seemed to work, but the various SVN compiles (like the Gadget Factory SVN version) had the timeout issue.[/quote]
After experiencing client timeouts, I found a post somewhere nearby that mentioned tweaking the driver timeout properties. For myself (BPv3/5.10 on WinXP Pro) I appear to have fixed the client time outs by adjusting the driver's Latency Timer setting instead of the Minimum Read Timeout (I left both Minimum Read and Write Timeout at 0, and USB Transfer Sizes at 4096 each) as, I think, was mentioned in the post. Here are my client timeout results versus Latency Timer value:
Latency Timer Timeouts?
8 (default) yes
6 yes
5 no
4 no
1 no
I chose to set it to 4.
I've seen these timeouts as well; my client does three attempts in order to get an 'SLA1' reply from the device after a reset and 0x02 command has been sent. I see that three attempts is not always sufficient. If I enlarge this to five, it appears to work. Will test this further tonight...
Tinkering with the driver's latency timers might also be a good solution; though not everybody might be to keen on doing that.
Presuming that the client's message processing logic is correct ("if I send this command, I should expect this response..."), from the results above, it looks to me as if the driver were holding off transmissions and/or hoarding incoming data. It appears that the client intermittently does not see what was sent by the service in Step 3 (it just hangs), and completely in Step 11 (a valid response was returned for each command).
In my mind, this begs the question "Can the driver be operated in a non-buffered mode?" Along these lines, I disabled the "16550 UART FIFO" in the driver Properties, but I still saw the same results. I wondered if that setting was actually hooked to any real functionality, since the Properties dialog was the same as for the standard driver real on-board 16550 ports (non-USB). I guess I could research the Prolific implementation more.
Perhaps these results are specific to the Prolific driver only.
When I get a chance, I will look at the behavior with the Bus Pirate and its FTDI implementation.
[quote author="jawi"]@ian or flubberlab: could you provide me some details on what is not working? Does it abort the capture stating it cannot find the device, or doesn't it do anything, or ...?
[/quote]
I tested BPv3/5.10 and client 0.9.2 again. Works fine with driver tweaks to cure timeout.
Must be me missing something... Sorry for the false alarm.
I am working on getting the trigger (and slow sample rate...) implemented in the BP, but have run into a snag getting the ICD2 to talk to the board. I am getting the "ICDWarn0020: Invalid target device id (expected=0x447, read=0x0)" diagnostic even though the Self Test passes and voltage check is nominal. I have tried three different computers and two MPLAB versions. One of the configurations works, two do not.
I have a support ticket going with Microchip. I suspect induced ambient noise, but I am blind to see since my digital scopes are out of commission. When I get my OLS.. (but then why would I still want the BP LA...).
As a reality check, can someone confirm if they have been successful developing for a stock BPv3 with MPLAB and an ICD2?
Thanks.
Yup, I do on almost a daily basis, with stock BPv3a and BPv3b from Seeed. Are the PGC and PGD pins correct way around? is the icd2 power input connected to the ICSP power pin?
Thanks Ian.
I figured so, but just wanted to confirm.
Mine is from Seeed also. Yes, pinout is OK. Correct operation on one system confirms.
How long is your ICSP cable? Mine is 15 inches.
I use a 4inch cable, but it is connected to a telephone box with the wires broken out to a screw terminal. It isn't the best setup :)
For example:
http://hackaday.com/2008/12/01/bus-pira ... -and-more/ (http://hackaday.com/2008/12/01/bus-pirate-firmware-update-v0c-jtag-and-more/)
The "Invalid target device id " problem turned out to be an intermittent connection with the ICD2's RJ11 jack and ICSP cable connector.
After some driver installation grief (when I switched USB ports, I had to be careful to choose the OEM**.INF file instead of the one from the MPLAB ICD2 installation directory), I have been generally successful at debugging, with some notable exceptions:
(1) occasionally MPLAB never returns from a program verify operation (I notified Microchip Support)
(2) MPLAB does not show disassembler view and current execution point when I step through code that has no source file (e.g. JMP to bootloader at reset--I inserted a breakpoint at 0)
(3) occasional driver-induced BSODs
Maybe I need another reality check. Have you experienced any of these?
Thanks for listening to my vents. I am an ICD2 newbie. My real purpose here is to, of course, make as many AVR converts as possible!!! (joke, hopefully humorous)
I solved #2 with a little manual intervention.
Actually, MPLAB is hanging on program verification (PGC and PGD are low) quite regularly (~50%), so I am stuck for now while I work with Microchip to figure things out.
I have occasional MPLAB issues when running the debugger. Sometimes it won't pause and sticks in debug mode. If I crash everything out the ICD2 is gone and won't appear after MPLAB restarts, or after a replug. Only a full system reboot will get it back. This only happens occasionally, like once every few months.
Thank you for the data point.
Here is an updated SUMP service module that I have ported to, and tested on, the Bus Pirate.
Specifications:
- Sample clock source (32 MHz CPU clock):
---- Internal, 5.9 Hz to 108.8 kHz, jitter = -0/+250 ns
---- External (via AUX pin), rising or falling, 0 Hz to 100.6 kHz, jitter = -0/+563 ns (falling), -0/+625ns (rising)
- Trigger
---- Parallel only
---- Conforms to SUMP basic trigger system (4 sum terms, each with mask/value/delay/level/action)
---- Stages are evaluated sequentially, i.e. 1-2-3-4, on each sample
-Other
---- Sample buffer is pre-filled with telltale data (0,1,2...255,0,1...) to help indicate when a trigger occurs before the pre-trigger buffer is filled.
---- OLS internal test mode supported (data = 0,1,2...255,0,1...)
User Interface:
MODE LED states versus logic analyzer states (in operational order):
Logic Analyzer state .............................................. MODE LED state
---------------------------------------------------------------------------------------------
0. Idle (waiting for client command) -------------------------- OFF
1. Triggers armed; pre-trigger data is being acquired ------ ON
2. Triggers armed; pre-trigger data buffer is full ------------ OFF/ON (toggle every sample)
3. Trigger condition detected, trigger delays expired,
and post-trigger data is being acquired ----------------------- ON
4. All post-trigger data has been acquired; transmission
to client has completed (Same as Idle state). ---------------- OFF
I needed to enable compiler speed optimization and change the memory models (see source file) to achieve 100 kHz sample rates. I plan on looking into the possibility of setting compiler options within the source file, so that the makefile need not be changed.
I have included a hex image of the code--based on 5_10 (r564)--with all modules, except SUMP, disabled.
Nice work, thank you for sharing. We'll post up a call for testers.
The triggering stuff is pretty hard in a microcontoller (for accurate timing). We could probably offload a lot of it to a CPLD using the simple logic analyzer core I made in verilog:
http://dangerousprototypes.com/docs/Lul ... er#Trigger (http://dangerousprototypes.com/docs/Lulu:_Yet_another_logic_analyzer#Trigger)
The example only has 1 layer of trigger, but if the SRAM driver is removed it could probably support 3 levels (with serial configuration interface) no problem. I just got the PCB for the Logic Shrimp v2 today, it uses this same basic concept. I'll try to stuff it today and try it out.
Maybe we need a support group called LADAA (Logic Analyzer Design Addicts Anonymous)-----not!
Yes, a (slow) uC-only design has its inherent performance limits, but it was a nice puzzle.
Keep up the triggering ideas; a logic analyzer is only as good as its trigger (or depth, perhaps, if you have an offline trigger/analyzer...).
I look forward to looking at the OLS Advanced Triggering to see what is possible, since I was unsuccessful achieving a trigger on duration-type conditions with the Basic (SUMP) trigger.
Maybe we need a support group called LADAA (Logic Analyzer Design Addicts Anonymous)
I think so :) It is a great project to learn a new technology because it can start so simple (run and store pin states), and get really complex with triggers and timing. It was a really great first Verilog project.