This table is intended to describe the function of the I/O header pins for the side of the Bus Pirate depending on the selected mode but does not show the signals on the side of the connected device!
For UART mode this means that pin MOSI is TX (Transmit Data) and pin MISO is RX (Receive Data) for the Bus Pirate.
Thank you for pointing out that the description confused you (I am sure Ian will look into clearifying it or adding an example that will actually show how to connect the Bus Piarte to a UART or even better give examples how to connect devices to the Bus Pirate in all modes). Please let us know if this was not the part in the Bus Pirate manual that confused you.
I should have noticed it but I didn't pay any real attention to the details of the procedure for "unbricking" the WRT320N described on the DD-WRT forum except for the hardware part (hard reset via GPIO6). For those who are interested in CFE and the Linux utility [font=courier:]nvram[/font:], here are a few details:
CFE (Common Firmware Environment) is a firmware developed by Broadcom for 64-bit SB1 (Swarm) and 32-bit BCM47xx SOCs (the latter being the MCUs found in many Linksys, Buffalo and other brand routers). The CFE source including a functional specification is available from Broadcom. CFE is the environmet you connect to via the serial port (UART) of the router, [font=courier:]nvram[/font:] is one of the utilities provided by CFE. The source of the Broadcom implementation of the [font=courier:]nvram[/font:] utility is included in CFE - file: [font=courier:]/cfe-1.4.2/cfe/cf/ui_nvramcmds.c[/font:]
Quote
[font=courier:]nvram get[/font:] - Get the value of an nvram variable [font=courier:]nvram set[/font:]- Set the value of an nvram variable [font=courier:]nvram unset[/font:] - Delete an nvram variable and its value from memory [font=courier:]nvram show[/font:] - Display the names and values of all defined nvram variables [font=courier:]nvram commit[/font:] - Commit the current nvram variables and values to non-volatile memory [font=courier:]nvram erase[/font:] - This command deletes all nvram variables from both memory and non-volatile memory [font=courier:]nvram import[/font:] - This command converts standard environment variables into the corresponding nvram variables
nvram is a Unix/Linux (command line) utility for managing system variables stored in NVRAM (non-volatile RAM) which control the boot-time behaviour of the system. However the implementation of [font=courier:]nvram[/font:] (options) can vary in details depending on the platform/release:
SYNOPSIS nvram [ -p ] [ -f filename ] [ -d name ] [ name [= value ]] ...
DESCRIPTION The nvram command allows manipulation of firmware NVRAM variables. It can be used to get or set a variable. It can also be used to print all of the variables or set a list of variables from a file. Changes to NVRAM variables are only saved by clean restart or shutdown.
In principle, name can be any string. In practice, not all strings will be accepted. New World machines can create new variables as desired. Some variables require administrator privilege to get or set.
The given value must match the data type required for name. Binary data can be set using the %xx notation, where xx is the hex value of the byte. The type for new variables is always binary data.[/font:]
Thank your for your feedback! For those who try to be helpful good feedback - regardless if the reported result is negative or positive, even critique on how the help was provided - is the best help for the helper and a confirmation that their attempts to be helpful are appreciated. It will encourage them to continue to give help and improve on how they do it.
On the side: Oh memories, good old memories ... the days we hacked every device we could get our fingers on ... seem to return ... I just ordered a WRT610N and a WRT320N ...
First: Many Linkysy/Cisco routers have a ("hidden") serial port that is brought out inside the WAN/Internet port (RJ45 connector used to connect to the internet). This port is the same as the internal port (on the PCB you can see the traces leading to the same pins). Signal level is 3.3V!
You can connect to this port with a BusPirate (or a 3.3V serial to USB cable) as described above. From a terminal emulation (Hyperterminal, Tera Term etc.) you gain access to the console by holding down/typing the SPACE or ENTER key (not sure which, maybe any key) until the console responds and a prompt is displayed.
//EDIT: The "hidden" debug adapter inside the WAN/Internet port of the WRT320G is connected to the UART pads of the internal connector - given you have an adapter (very unlikely) there is no need to open the router for accessing the serial port/console. //
and a close-up:
I strongly suggest to attempt clearing the NVRAM via the serial port if possible before using the "hard-erasing" procedure (connecting GPIO6 to GND for about 10 seconds after powering on the router)!
@ACalcutt: I think there will be a way to unbrick your unit without using the JTAG gun.
I saw a number of people in the +30 page "Linksys WRT320N now supported" thread who reported the same or a very similar sounding problem - bricking their WRT320N when rebooting the router after they had received the message that the update had completed ... some never booted, others booted but failed later - in all cases the bricked WRT320Ns misbehaved in similar ways as described in this post and what you reported.
However, most (if not all) managed to recover their bricked WRT320G ... by "hard-erasing" the NVRAM following this procedure:
1. disconnect the router from power
2. open the case and connect contact GPIO6 to GND (i.e. the metal shield cover over the BCM4328 Draft n transceiver chip).
3. make sure that GPIO6 and GND are connected when applying power and stay connected for up to 10 sec. after you have applied power (you may have to repeat this a couple of times and it may take more than 2 hands
4. Once the blue power LED changes from blinking to steady on you have succeeded - the router is unbricked.
After this there should be no need to use the console/BusPirate - firmware updates/swaps (with original Linksys firmware or the latest DD-WRT release) can be installed via the web interface ... just make sure to set the router back to factory settings immediately before starting the firmware update.
If the router's serial port would be set to a different baudrate you would most likely see a stream of "wild" characters during boot-up.
I tested the above configuration (picture shows BusPirate 3.0 connected to the UART of a NSLU2):
NLSU2 has completed the init/boot phase and accepts commands in the Tera Term window with BusPirate in transparent UART bridge mode:
First you should check the BusPirate on a serial port (3.3-5V!!) that is known to work ... the simplest test is looping back pin MOSI to pin MISO on the BusPirate I/O header. For the test use exactly the same settings as for the router. Once you are in transparent UART mode press some keys on your keyboard. If the characters show in the terminal window (echo) the BusPirate is good!
// EDIT - Attention: Please read my next post before attempting the next step ("hard-erasing" the NVRAM)!!!! //
If you still can't use the console of the WRT320N, the hardware is either broken or the firmware (in Flash) and/or the variables (in NVRAM memory) are corrupted. If it's "just corrupted kernel image variables" in NVRAM you may still have a chance by first executing Eko's NOVRAM "hard-erase" procedure:
Right...here is "erase nvram" procedure. You need to open the router. Next to cpu you will see some gpio dots labeled like this: Code: GPIO11 o <-copper dot here GPIO12 GPIO15GPIO9 GPIO6 o <- copper dots oo o <--- this is gpio6 - short to ground
And you see 4 copper dots at corner of cpu. Cfe listens on gpio6 (like most other linksyses).
Disconnect power from router. Now get thin wire or needle and you need to ground GPIO6 (e.g to radio shield). Keep grounded, plug power (let somebody help you if needed), keep grounded for 6-8 s, release. This should erase nvram.
If the firmware image in Flash memory is not corrupted, the router may load it and boot the original firmware after the NVRAM "hard-erase" (some router models won't boot after NVRAM has been wiped) ... However, this should be the last measure to be taken because if the firmware can't be loaded from Flash after the NVRAM has been wiped, the router must be considered KIA (unless some way to use a JTAG interface can be found).
Good luck
P.S. all information given without any guarantee
P.S.S. sorry for the edits and post-edits, took a bit for my unbricking/modding memories to resurface ...
wow, this is coming together quite nicely and faster than I thought ...
One more suggestion (for now): I'd add a pin for +5V (in) on the UART (legacy) header ... the +5V trace from the USB connector to the power converters runs right by the connector ... to allow for use of the LA without connecting it to a USB device ... and (so this will require an extra jumper to select between USB power and external power) to allow for external powering in case the LA is used via USB on a laptop i.e. that can't provide sufficient power via USB or if header boards will be used that would kick up total power drain beyond what can be drawn from/provided by USB.
Today I found a low cost Spartan-3A evalauation kit by Avnet - Xilinx® Spartan®-3A Evaluation Kit with a surprisingly similar concept of Ian's and Jack's current design approach.
USB MCU (Cypress PSoC), SPI Flash, Spartan-3A FPGA for less than US$ 50. Now the really interesting part is the documentation on how they have interfaced the MCU, SPI Flash and FPGA and how the MCU controlls everything. On top of that the MCU acts as an intelligent communication interface and there is a quite extensive API for application software development on the PC side (so only for Windows) ... lots of good and detailed documentation (schematics, API reference, user interface ...).
- Xilinx Spartan-3A Evaluation Kit - User Guide - Application Programmer Implementation Guide - Serial Flash (SPI) Configuration - Slave Serial Configuration from a Processor - Schematics for Xilinx Spartan-3A Evaluation Kit
The MCU on their bord controlls the FPGA - unless a JTAG interface is attached. The MCU controlls the FPGA "configuration" pins thus allowing various configuration options - Master SPI Mode (from SPI Flash), Slave SPI mode (direct load from PC via MCU into the FPGA) and Parallel Flash (BPI) Mode (not of interest in this project).
Eventhough it's a Spartan-3A based design most if not all details apply to the Spartan-3E as well.
... you are right, Jack did not design the "FPGA Based Logic Analyzer". Indeed, some details about the SUMP LA project got never mentioned in this discussion. Lets pay due respect to those who deserve it (in chronological order) ... along the lines better too late than never ... and use this opportunity to give some essential links as well:
Jack Gassett has ported the SUMP LA design to his Butterfly Platform, implemented some improvements to the LA VHDL design as well as the SUMP Java Client and prepared some nice tutorials (Jack, please forgive, if I missed something).
Ian came up with the great idea of putting (or you may say "slapping") the SUMP LA design on a very low cost board (US$ 30-40) and Jack offered his cooperation and support for this project by bringing in the FPGA side of the design and his experience.
To my knowledge this will be the first application specific implementation of the SUMP Logic Analyzer on a single PCB that will allow users to get their hands on a low cost, open source, FPGA based logic analyzer they can put to use out of the box without having to install and get familiar with FPGA development environments and overfeatured FPGA boards.
All comparable previous LA implementations seem to have used standard FPGA evaluation/development boards with adapter boards (starting at around US$ 100) and relied on (at least parts of) FPGA development environments for loading the FPGA configuration before the application could be used ...
P.S. ... and yes, you may call me lazy. Most of this information (and far more) can be found on the Logic Analyzer project pages at Jack's Gadget Factory site.
Exactly, it's more or less intended as an "on-chip" logic analyzer for FPGA projects.
Quote
quoted from the OpenVeriFLA version 1.0.3 Reference Manual:
It helps in on-board testing and debugging of the FPGA projects. This is done by real-time capturing and then graphically displaying the signals transitions that happen inside the FPGA chip.
... The java application receives the captured data and saves it on the disk in a file named capture.v. This file is a behavioural verilog HDL file. An Verilog HDL simulator with a graphical viewer for the signals is necessary in order to simulate capture.v and view the captured data.
While the FPGA implementation of the LA logic seems to follow a concept similar to Jacks SUMP LA implementation and even a Java application is used on the PC to receive and convert the captured data, the design is in no way SUMP compatible and relies on the presence of ISE or some other "Verilog HDL simulator with a graphical viewer" on the PC. The project does not appear to be active or well documented - it will take to go through both the Verilog and the Java code to get a full understanding and to make any use of it ...
LukeS, that's exactly what I am proposing now (see above): No buffers on the main board!
Instead we should release a 16-bit 5V tolerant buffer board (like Jacks Butterfly buffer widget) as a first wing/add-on board along with the LA main board. Everyone will be free to decide if they need 5V tolerance and if they want it for 16 or 32 channels. Beyond that it would keep all options open for a broad line of widgets/add-ons like voltage shifters/converters, DAs, ADs, pattern generators etc. Users could design widgets and customize them to their needs.
I use the BP to "hack" undocumented/proprietary equipment, monitor/reverse-engineer serial protocols even in the filed and for debugging ... well, just started doing such things about two weeks ago after the first BPs v3.0 arrived. Before we used far bulkier equipment ...
I am not so much concerned about scratches on the case as the weight. Like ian and pppd I'd like it heavy enough so it will stay in place where I put it and not get pulled around/down by the USB cable.
Looking forward to see the final product on your web store ... made the link to your blog sticky but had problems accessing the shop !?!?
I know what you are talking about - I run KiCAD and Eagle for my private projects and to follow/view Open Source/GPL projects while we use Cadence/OrCAD in the company (by customer demand).
for non-native English speakers English and English are two different languages when it comes to explaining technical details - in particular if you are an EE or not used to technical English at all and try to explain mechanical details (I say this from experience)
I think I had a pretty similar idea to what pppd tried to explain but I kept quiet because I didn't know how to express myself precisely (without looking up too many words) Let me try:
Because you can't put the PCB directly on the metal plate (bottom layer) pppd suggested to put an extra acrylic layer with a rectangular cut-out (the dimensions of the cut-out being slightly smaller than the footprint of the PCB) right above the metal plate that would act as a spacer for the PCB - this layer should be 1/8 thick as the contacts of the headers stick out more than 1/16 from the bottom side of the PCB.
This would lead to something like this (from top to bottom): 1. acrylic cover layer with breakouts for the vertical connectors/headers and the USB connector/jack 2. acrylic layer 1 (1/8) surrounding the Bus Pirate PCB 3. acrylic layer 2 (1/8) surrounding the Bus Birate PCB 4. extra acryl layer that acts as a holding frame and spacer for the Bus Pirate PCB - with a rectangular hole/cut-out in the middle that is slightly smaller than the PCB ... allowing the sides of the PCB to rest on this frame - so the contacts on the underside of the PCB will not touch the metal plate. 5. metal base layer with threaded holes for the screws (yup, it will require longer screws) 6. rubber feet
P.S. acryl(ic) == plexiglas, PMMA
ril3y, your design is great ... we love the Bus Pirate and use it quite a bit. So we look for a "heavy duty" version of your design, toss in our ideas and I will buy one or two regardless if there will be an option with a metal plate or not.
I think that's why he may have used the rather oversized, heavy screws
I really like the design, almost perfect ... but true, adding a heavy metal plate (i.e. bottom) would make it the perfect housing for the Bus Pirate ...
Eagle by Cadsoft(dot)de is free for private/non-commercial use in the freeware version and available for Linux, Mac OS X and Windows (in alphabetic oder)
I use the freeware version of Eagle at home and on my laptop and so far I have been able to view, edit and export/convert all of Ian's (and Seeedstudios) Eagle projects I have looked at.
It really pays off to install Eagle (about 70MB once intalled) if you want to follow the projects and see/verify the details.
audihacked, thnx for the links ... I think the CIPPICL-X soft-IP has been around for some time but I couldn't find any details on the implementation nor on the license model/cost ... it may not be free
This is all I found about the CIPPICL-X/CIPPIC softcore: Cheetah Hi-Tech, Inc. - Products and 2K word instruction ROM - even 8K word instruction ROM for the CIPPIC implementation - may not be enough code space for the project
I think Ian and Jack decided to go for a "hard MCU" for various reasons like
- use Jacks proven LA implementation for the Spartan-3E 250 without any/many changes - keep the design open for different implementations/different MCUs - allow for as much as possible of the FPGAs RAM to be used as a capture buffer ...
... the resources of the XC3S250E are kind of limited and the XC3S500E - the "largest" Spartan-3E available in a 100-VQFP package - would cost about US$ 7 extra ... eating up US$ 20 of a targeted retail price of US$ 40 max.
Most of this information (and far more) can be found on the 
