New Client: OLSFront

[jadew]

Hey guys!

Hope this is the right place. I've been working on a client for OLS, it's in alpha at the moment, but very much usable. I could use some feedback and maybe samples for different protocols that I can't generate samples for.

This is the project's page (unfinished as well): http://dumb.ro/lafront/

It's a windows native application, however it runs under the last stable version of WINE as well, but a bit crippled.
In order to run it under WINE, you have to provide the COM port as explained here: http://www.winehq.org/docs/wineusr-guide/misc-things-to-configure

Under WINE, you won't be able to move the toolbars and it won't remember the layout (will probably fix that in future versions).

Thanks

[danielsoy]

hi jadew

is this project, still alive?

were lucky decoding microwire protocol?

here, may download some captures that i got reading and writing a 93c86 memory
with ponyprog.

http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=4456

[jadew]

Hi danielsoy,

There wasn't much interest for this project so I stopped working on it, however, if you can use my software to capture some microwire data, I can take a look at the data and create a parser for it.

From what I'm reading, it appears that microwire is very similar to SPI, so you should give it a try with the SPI parser first, to make sure it's not already working and if you're still having problems I'll dive into it.

Please let me know how it goes.

Edit: in case you tried to access the site today, it was down for a bit, but now it's back online.
Edit2: I just took a look over the microwire protocol and it's a bit different than SPI, so I started writing a parser for it. I'll be back with info on how it goes.

[danielsoy]

That´s right, are very similar, but seems that they got lil differences.

Will try to get into your site, cause i could not when I tried.

If I can get some captures with your client, will tell what happens.

Cheers!

[jadew]

Hey, I just uploaded a new version in there, I added an import feature, which right now imports files from Jawi's client. I needed that in order to load your samples.

I have some bad news and some good news. The good news is that I made a microwire parser and it's working properly I think. The bad news is that it's not telling you what kind of operation it is, because I noticed that different devices have different opcodes.

Edit: On the other hand, I don't think it's going to be an issue to remember the bit codes for the few opcodes this chips are supporting (most of them only having 2 bit opcodes).

I might add an option in the future that displays data related to common protocols on top of microwire.

http://dumb.ro/lafront/microwire.png this is your sample data.


Edit2: If you really want it to tell you what the opcodes mean, you can edit the parser yourself:
Tools -> Protocol Manager. Select the uWire protocol, hit Develop and then in the new dialog hit Edit (it will ask you to pick an editor).
The parsers are written in JS so it shouldn't be too hard to modify them (sorry there are no docs yet on the API, but you'll probably figure out fast what it all means). Also sorry if it's missing comments or if it's not as clear as it should be, I kinda rushed it.

Edit3: Let me know if, while looking into microwire, you stumbled upon some documents that properly explain the protocol and the way it's normally used. For one, it wasn't very clear to me what the start condition is. It appears that microwire devices have a trigger on the rising edge of the clock line and that's when they check CS and DI, if they're both high, it gets activated, so basically the trigger would be when all 3 lines are high (CS, DI and SK). Let me know if you think this is not the standard behavior or if you found some documents that might clarify the start condition.

What intrigues me is that in your examples, before any transfer begins, CS seems to be pulled low for a bit, just before releasing it back to a high state. However, that might be to ensure that the device gets reset to idle state, before starting a new transfer. Just to clarify, I'm not referring to the stop condition (which is low CS), but to the fact that it looks like the master is actually pulling CS low before pulling it high for the first time, which doesn't seem to be necesary. My best guess is that it's doing it just in case, but it could also be part of the protocol and I'm not aware of it.

[danielsoy]

Amazing job !!

Here, i ve uploaded some microwire related info in a zip file.

http://www.4shared.com/archive/GT_4wavx/Microwire_info.html

As you may see at those docs, there is just 4 opcodes, read, write, eraseall and writeall.

Will try to edit the parser to make it shows opcodes .

About CS line pulling down at the very beining of ponyprog communicating with eeprom , guess that ponyprog
make it to avoid any corruption of data UNselecting any target device, until programmer is ready to go. Its just
a guess...

[jadew]

Thank you,

I've updated the parser to show the data a little nicer so you might want to download the the whole thing again (sorry - only the parser file has changed).

Is it decoding properly?

Edit:
To make it show different opcodes you'll have to make the opcode be accumulated as a number, instead of a string (I did this for the opcode because I figured it would only be shown in binary).

So in order to make it work the way you want it to, in the section that's handling the opcode, you need to:

1) Replace:

Code: Select all

var opcode = '';

with

Code: Select all

var opcode = 0;

and

Code: Select all

opcode += sample.level(di);

with

Code: Select all

opcode <<= 1;
opcode |= sample.level(di);

2) Add:

Code: Select all

switch (opcode)
{
   case 0: opcode = 'SOMETHING'; break;
   case 1: opcode = 'SOMETHING ELSE'; break;
   case 2: opcode = 'etc'; break;

   default: opcode = bin(opcode);  // this means that the opcode will be displayed as binary, if no match is found in this list.
}

before

Code: Select all

if (ok)
   addData(di, start, end, 'O ' + opcode);
else
   addData(di, start, sample, 'O ' + opcode, 'Premature Stop', true);

You can also remove the 'O ' + from the output section, since having actual names for the opcode doesn't call for it to be marked in any way anymore.

Also, Instead of modifying the microwire parser, you can simply copy it and have another one for the specific protocol your handling. I trust you'll figure out how to use the parser developer and what the info() function does (at the top of the parser script).

PS: Thanks for the zip

Edit2:
Thanks again for the zip, that application note from Microchip (AN999) shed light on the start bit and it seems I was right, there are no preconditions. I will however move the annotation from the clock line to the data line (altho I know the clock line is the important one there, but I guess it makes more sense for the start bit to be on the data line), in the next revision.

[danielsoy]

Hi again,

Already uploaded my first capture file with olsfront and firmware that is being reading from 93c86 eeprom
configured as 1024x16 bits.

ch0 CS
ch1 Clock
ch2 DI
ch3 DO


capture file
http://www.4shared.com/file/n2VBaU7X/reading_93c86__1024x16bits_fro.html

firmware
http://www.4shared.com/file/0Ico7xOq/firmware_93c86_as_1024x16_read.html

And a video capture made during sampling.
http://youtu.be/YQuS89mkWCI


Tomorrow will try to find out, how to decode this capture.

Please let me know jadew, how may i help anytime.

[danielsoy]

Sorry, just find out the green plus button on the left, to access the decoder menu...

Now its 12pm, and i am going to sleep, tomorrow will take a closer look to decoded data, that look
pretty good...cant wait...

[jadew]

Hey,

In the protocol window, you click the + sign and select the microwire protocol.

Also I noticed you're scrolling a lot, you can zoom in and out by holding CTRL down and using the mouse wheel.

You should read this instructions, they will give you a quick start on making the best use out of it.
http://dumb.ro/lafront/#quickstart

Let me know how it goes and if I can help you with anything else.

[danielsoy]

First decoding are very good, just two errors.

Uploaded a video , here may see a 93c86 memory, configured as 2048x8 bits(ORG 0) being read from ponyprog.

There are two decoding errors at 20,4ms and 24 ms. A 07h byte decoded as 03h, and a 0B byte, as 03h too.
The other bytes, are decoded right.

capture video
http://youtu.be/SQ_Rto90WOA

firm and capture zip file
http://www.4shared.com/rar/6p38e4_s/fir ... _2048.html

Will take more captures to see how it goes, thanks again.

[jadew]

Hey, you are right, it appears that the DO line has to be sampled on the falling edge on that chip, however I noticed that on other chips, it needs to be sampled on the rising edge.

I'll update the parser to allow the edge selection for the DO line and let you know.

[jadew]

Ok,

I've updated the parser to allow you to select on which edge the DO line should be sampled: http://dumb.ro/lafront/protocols/microwire.js

Please use the same samples as in the video (if you have them saved) and see if that fixes the issue.

Thanks

[danielsoy]

so kind..will try and tell.

[jadew]

One more thing, I noticed in your videos that the "Decoded" window is hidden. If that's by mistake, you can enable it from the View -> Windows -> Decoded. This will give you a better overview of the decoded data.