EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: brainwash on August 04, 2013, 05:50:55 pm
-
This has been my struggle for the past couple of years, getting some decent tools to do protocol debugging. I have a few tools laying around:
- BusPirate - crappy "UI", pretty hard to automate (properly), not much info around
- Salea LA - nice UI, nothing really to automate
- various obscure dev boards that also have LA interface
Most of the time I just go with the approach of looking for existing "Arduino" code, reading the datasheet and then whipping up a small program to upload on a dev board with a simple hardcoded serial port "UI".
Are there any tools that have the following features?
- library of parts: accelerometers, ibutton, lcd, ...
- visual logic analyzer like the salea one
- the possibility to also do injection on the pins (read and write, not just readonly)
- the ability to write simple libraries or at least macros (read register 5A, write the LSB value to another register...)
I haven't really looked that hard but afaik there is no unique tool that does all this so for me it's faster to just code something quick. I know about SUMP but there are no decoders available.
Just found out about sigrok, is anyone it? Last time I tried it there was only some cli available for windows.
-
I've researched a bit and there doesn't seem to be anything within hobbyist range that is able to do protocol decoding and injection/encoding.
The BusPirate does this but cannot be automated and there is no proper UI.
The GoodFet comes close by providing an API with examples for some protocols or devices, but no UI.
The Usbee/Salea software and pods cannot replay complex signals.
Pickit2/3 has UI and injection (stimulus) but no decoder.
Perhaps I was spoiled by Vector's CANalyzer/CANoe (>10k$) to think that something similar would be available for affordable prices.
-
You could check out Total Phase. I would say that they are on the upper end of hobbyist grade but can be automated using their API.
You won't find one device that will do all of the protocols in one but each one is solid. Aardvark for SPI and I2C and Komodo for CAN.
Having used both CANalyzer and Komodo, I think that I prefer Komodo because it has less driver issues and is a few orders of magnitude cheaper. There are quite a few advanced features of CANalyzer that Komodo doesn't do out of the box but I didn't use them frequently enough.
Sent from my iPhone using Tapatalk 2
-
The scanalogic allows playback http://www.ikalogic.com/ikalogic-products/scanalogic-2/ (http://www.ikalogic.com/ikalogic-products/scanalogic-2/)
-
I remember that the buspirate is open source and open hardware device
so automating things should not be a big problem ?
-
Total Phase software seems to come closest to the real thing so far. But I don't understand why they must have two boards (Aardvark and Beagle) to do almost identical things. Baring that, the software is key and it looks to be the best out of the bunch. Enterprise-level pricing, but still ok.
Yes, BusPirate is opensource, but so is any dev board. There is nothing really special about it. The only positive point is that it can be used independently (sort of) without any software or host PC. There's not something even close to scripting unless you consider making scripts in python to: press P, check if this thing outputs some menu, press another key, read back screen, ... Good luck trying to read a 1Mb SPI flash in a decent amount of time. I still use it from time to time though.
I've seen scanalogic but I cannot figure out if they can output the decoded protocols. I only see FM, PWM, USART in the output window. And decoding is only half the job, I don't see any encoding features. It's really cheap though, less than what I paid for the bus pirate.
I think I'll just stick to my current solution for now and maybe develop a small open-source Java tool/firmware combination. When I say firmware I really mean sketch. The firmware side should translate I2C, SPI and other protocol logic to [virtual serial?] USB I/O. That's because just shifting the bare pin changes via USB is really slow. Everything else can be done on the PC/host side in some Python script. Java can take a python parser as a library and can provide nice portable GUIs.
Side rant: I really hate when Linux-lovers get their hand on software and in order to use it on Windows you have to go through ten thousand hoops: download GTK, cygwin, python. That is if you are lucky and it's actually compiled. It's a virtual fence that keeps honest and willing people out. I'm looking at you: gimp, sigrok, octave, ... I keep some VMs ready for that but <10% of the programmers I know actually want to go through that trouble.
-
Yes, BusPirate is opensource, but so is any dev board. There is nothing really special about it. The only positive point is that it can be used independently (sort of) without any software or host PC. There's not something even close to scripting unless you consider making scripts in python to: press P, check if this thing outputs some menu, press another key, read back screen, ... Good luck trying to read a 1Mb SPI flash in a decent amount of time. I still use it from time to time though.
Wasn't there a binary mode designed for scripting and faster transfers (not that it's going to be a speed demon either way)?
Side rant: I really hate when Linux-lovers get their hand on software and in order to use it on Windows you have to go through ten thousand hoops: download GTK, cygwin, python. That is if you are lucky and it's actually compiled. It's a virtual fence that keeps honest and willing people out. I'm looking at you: gimp, sigrok, octave, ... I keep some VMs ready for that but <10% of the programmers I know actually want to go through that trouble.
So what was that software like before the Linux-based developers got their hands on it?
-
Shareware was the word of the day back then :) And a lot of VB/Delphi dependencies.
It's a good thing that continuous build/integration environments are widespread now, at least Win32 builds are automated for big projects.
I missed the memo on the binary mode, it seems exactly what I needed, thanks for the update.
-
Total Phase software seems to come closest to the real thing so far. But I don't understand why they must have two boards (Aardvark and Beagle) to do almost identical things. Baring that, the software is key and it looks to be the best out of the bunch. Enterprise-level pricing, but still ok.
As far as I know, Aardvark can do everything Beagle can do. I don't know why both exist either. The software is really good though.
Sent from my iPhone using Tapatalk 2
-
From what I can tell, the Aardvark uses the FTDI interface IC (which has hardware support for SPI, JTAG and IIC). The costly hardware could likely be duplicated using a $20 UM232H (FT232H dev board), though the eeprom might contain some mandatory info.
-
It's more than an FTDI, there is also an ATmega in there.
/http://airvariable.asablo.jp/blog/2011/08/30/6085004
Speaking of FTDI though, if you have some software skills, maybe that chip along is a better option than some of the other devices...
I think the moral of the story and Dave says this all of the time, sure the hardware cost might be $20 or less but they have really good software that they include with the device and that is not cheap to develop!
-
I remember that the buspirate is open source and open hardware device
so automating things should not be a big problem ?
Pardon me while i climb on my ranting box here for a second...
Well, if it's not a big problem..WHY ISN'T IT IN ALREADY ?
That is the endless problem with aal that open sores junk. Half baked , half finished, original maker lost interest, forked, forked again , now totally broken and a huge can of worms. 'But you have the source'... Sure.... I don't want the source, i don't care about the source. I want something that works , correctly and reliably, with an installer.
I dont want to recompile the kernerl , download 5000 patches , install eclipse and whtever toolchain required to compile the brainfart and then wade through a chunk of code , written by 10 different people l, each with their own style, that now looks like a hairball because it is patch on patch on patch and didn't have the right architecture to begin with...
Thank you for listening. -steps off box and walks away...-
-
As for the FTDI chip. RUN FOR THE HILLS !
I have been struggling with it for weeks. It is plagued by a silicon bug (glitches in spi mode 1 and 3...)
And the library is total crap. It even contains stupid mistakes like forgetting to dereference a pointer... You pass the data array using a pointer and the thing transmits the address the data is stored at instead of the data itself....
That library is compiled using a command line compiler. You need to install mingw , edit the code using notepad and compile it , there is no debig toolchain , no breakpoints , nothing. A texteditor and a commandline. It's like being nibbled to death by a single duck that puts in a half assed effort.
After weeks of work tracing the problems i wrote an extention in the linrary giving me raw access to the command processor. I now solve all the problems in the application program.
I am working on getting rid of their library altogether and simply hooking in to the core driver itself.
-
Do you really want to do that? Reminds me of this guy: http://spritesmods.com/?art=hddhack&page=3 (http://spritesmods.com/?art=hddhack&page=3)
The open hardware community is spoiling us with cheap gadgets but unfortunately, most of the time, the software is not up-to-par. It takes probably at least 1-man-year to come up with really good stuff and I think the OSHW shops just don't want to invest that time.
I'm not 100% certain but I think that business model went ok for Saleae, they are still selling their dongles at a profit and able to pay the developers with the proceedings. Dangerous Prototypes has a single developer (part time, if that) developing for both BPs.
So yeah, I kind of balk at the 300E price point of Aardvark/Beagle when it has of 10-20$ hardware and reuses the same software across several HW platforms. Kind of wish there was some realistic way to do kickstarters for open source software&firmware.
-
Do you really want to do that? Reminds me of this guy: http://spritesmods.com/?art=hddhack&page=3 (http://spritesmods.com/?art=hddhack&page=3)
The funny thing is, the chip that the guy is referencing in that article is quite likely free_electron's design... so yes he probably really DOES want to do that... lol
-
Wait, how?!
-
Yeah, that 'smooth' chip is one i worked on.
Basically what that guy did is launch the minicon in the drive. ( although he did it in a very complicated way ) .... all you need is a level shifter and serial port or a ftdi232 and usb port , hook it to the jumpers and send a <return> during powerup.
The minicon has a few basic commands, one is writing to memory locations.... and that's all i can say about that...
yes, harddisks actually have an RTOS running the drive.
-
Props to you for working on such a mission-critical product!
Actually, the guy did more than just hooking to the console: he booted linux on that chip. The serial port was just used to trigger some code that was injected into the flash chip holding the firmware: http://spritesmods.com/?art=hddhack&page=7 (http://spritesmods.com/?art=hddhack&page=7)
But I think I see where you are going, that all these hoops and decompilation was not needed. Nevertheless, I think the "goal" was to make a permanent hack that does not require opening the computer.
-
The BusPirate does this but cannot be automated and there is no proper UI.
There is a UI , actually there are several. The best one is only available as source code though but it isn't difficult to understand and even expand upon.
https://bitbucket.org/ronanpaixao/pirateship/overview (https://bitbucket.org/ronanpaixao/pirateship/overview)
The closest thing to an actual off the shelf product that doesn't break the bank is the MSO -19:
http://www.linkinstruments.com/mso19f.htm#PG (http://www.linkinstruments.com/mso19f.htm#PG)
-
Thanks for the links.
Like impulse buy there's also impulse rant: PirateShip is a project that has no binaries, no downloads, no wiki, no instructions on how to compile (I see it's C++ & QT) a homepage that's dead and no revision history.
I should probably stop complaining now and start writing code.
-
PirateShip is a project that has no binaries, no downloads, no wiki, no instructions on how to compile (I see it's C++ & QT) a homepage that's dead and no revision history.
The programmer had some problems with his hosting. He last posted on the DP site a month or so ago.
It compiles fine, did it just a week ago. You need QT version 4.6
-
he booted linux on that chip.
:palm: Why do people immediately think -LINUX- when they see a command prompt ?
Do you really think the RTOS in a harddisk is linux ? linux doesn't come close to the level of reliability of the drive firmware. Linux is to dos what the driveware is to linux ...
The drive RTOS is specifically designed for that application.
What the guy did is dump a block of memory and disassembled it. fine. then he patched some stuff in the eeprom and managed to run a hello world program. fine.
so he managed to write hello world to the platter .. fine...
he also corrupted the entire drive..
If you try this while the drive is being accessed from a running filesystem you can kiss the data stored on it goodbye. Anything you will try to inject will mess up the internal timing with catastrophic data corruption as a result.
-
No, it's not like that but the details are scarce. Here are the steps that I figured out:
- top terminal is running Linux on a full fledged computer
- bottom terminal is connected to the serial port of the hdd, it's read-only, probably under the same linux instance
- attacked harddrive is mounted on the host linux computer
- the injected firmware is listening for the file '/home/jeroen/dummy' which is treated like an input pipe / stdio
- issuing 'HD, live' to that dummy file echoes some characters back on minicom
- two files 'kernel.sect' and 'initrd.sect' are copied to '/home/jeroen' which are probably make up a linux kernel that is sector-aligned (not sure how this sector/cylinder/head stuff works)
- speculating here but the above files are copied somehow to the flash memory of the ARM chip at the code reset address
- issuing 'HD, lnx!' to the dummy file forces the injected code to trigger a reset which will boot the ARM processor into the custom ARM linux distribution
You can see in the video that the Linux boot screen is showing the Feroceon processor, ARMv6, 48 MB of memory and 0.13 Bogomips. Either that does not seem impressive to you or you thought something else was going on. To me it seems almost like magic.
Edit: I agree on the data corruption fact but just as a thought maybe the injected code can be disguised inside the spin-down/spin-up request cycle.
-
Side rant: I really hate when Linux-lovers get their hand on software and in order to use it on Windows you have to go through ten thousand hoops: download GTK, cygwin, python. That is if you are lucky and it's actually compiled. It's a virtual fence that keeps honest and willing people out. I'm looking at you: gimp, sigrok, octave, ... I keep some VMs ready for that but <10% of the programmers I know actually want to go through that trouble.
So step up and help out.
Speaking for sigrok, I can tell you for a fact that the reason our windows support is incomplete is because we just never see any windows developers wanting to help out. Even things like doing a test compile and packaging up a binary -- not a single offer. We have people do this stuff all the time for even relatively obscure operating systems like NetBSD, and as a result sigrok compiles and runs there just fine.
You can rant and rage against "open sores" with all manner of silly arguments, but we're just people willing to step up and put LOTS of work into this. It would perhaps be more interesting for you to either help out where you can, or find people that are willing to do it. THAT will get results.
-
Kudos to you.
I have a Windows laptop that I can perhaps leave running for 24h for doing the builds. If 24/7 is not required I can set up one of my Windows VMs to do that whenever it's needed, perhaps once a week? I have a few tools that can be interfaced with sigrok and willing to also help on those.
It's not a rant at sigrok or its developers, it's at the fact that without a little bit of the extra mile all these efforts fail to reach 90% of the audience. Sure, Maemo is nice but iOS reaches far more people that rely on that single fact: convenience.
I'm a Java coder myself and so are 90% of my [developer] friends. I only use C for uC because there are no better choices. Using C/C++ for open-source locks a lot of willing and able people out. I won't go into Java vs C++ debate because I understand the needs and limitations, but actively avoiding Java for computer programs is a bit silly.
-
Kudos to you.
I have a Windows laptop that I can perhaps leave running for 24h for doing the builds. If 24/7 is not required I can set up one of my Windows VMs to do that whenever it's needed, perhaps once a week?
That sounds great, thanks! It would be very helpful if you could take a look at libsigrok 0.2.1, which we released this week. More is needed than just a compile run of course -- testing stuff out and creating bug reports for features, drivers etc that don't work on windows would advance things even more. As would fixing those things, but hey :-)
I have a few tools that can be interfaced with sigrok and willing to also help on those.
That's even more interesting. Drop by the IRC channel or mailing list (contact details on sigrok.org) and tell us about it -- we like to make sure nobody's doing duplicate work on devices, and in any case we can help you get started. There is a lot you can do even without programming C: we do a lot of documenting on the wiki before we even start on a driver.
It's not a rant at sigrok or its developers, it's at the fact that without a little bit of the extra mile all these efforts fail to reach 90% of the audience.
And we are utterly, absolutely aware of this.
-
Hard drive pics (new 1tb WD Blue)
I see they're finally using bga ddr2 now.
WDHC8TD
http://imageshack.us/a/img541/8884/vanb.jpg (http://imageshack.us/a/img541/8884/vanb.jpg)
http://imageshack.us/a/img823/936/hqnk.jpg (http://imageshack.us/a/img823/936/hqnk.jpg)
They even left off the 100ohm diff clock termination on the ram. Really scrimping pennies (or its a nonstandard ram with builtin termination)
-
PIC32MX250F128B microcontroller is perfect, if you need I2C bus suppoort. You can also program the microcontroller from VB.NET and there are plenty of samples. You just need to search for "PIC32MX250F128b vb.net example"... There is also a very nice VB.NET example with source code that gives you I2C buss access to 16-bit ADC7414 temperature sensor via USB.
-
It's like being nibbled to death by a single duck that puts in a half assed effort.
That's a good one :-DD
-
Yeah, that 'smooth' chip is one i worked on.
Holy shit! You mean there's BASIC running inside my hard drive?
:P
-
Yeah, that 'smooth' chip is one i worked on.
Holy shit! You mean there's BASIC running inside my hard drive?
:P
Well it was the only way to make sure we didn't have problems with pointers , made by confused programmers using a language that got only a 'c' score...
Driveware is written in either assembly or a specific subset of c. ( ansi c with strict limitations on what can and cannot be done. The real low level code needs to be compiled as-is. No optimization allowed by the compiler. Code is compiled using RVDS and ARMCC.
Functions and procedures are running in lock-step with the mechanics.