HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Blogs
Sherlock Ohms

Bad Address Baffles the Software

NO RATINGS
View Comments: Oldest First|Newest First|Threaded View
Page 1/2  >  >>
naperlou
User Rank
Blogger
Keep telling stories
naperlou   9/26/2013 10:13:26 AM
NO RATINGS
Curt, I liked your article and your approach to solving the problem.  What really helps to debug hardware, especially in the field, is that knowledge base of actual experiences.  So, my suggestion is, keep exchanging those stories.  This column in Desing News is a great place to get such information as well.

TJ McDermott
User Rank
Blogger
Re: Keep telling stories
TJ McDermott   9/27/2013 12:49:35 AM
NO RATINGS
The trick though, is to remember the stories.  That's why they retire engineers - their hard drives get full.

a.saji
User Rank
Silver
Re: Keep telling stories
a.saji   9/27/2013 7:02:19 AM
NO RATINGS
@TJ: Even though you remember the stories, it will vanish with you once you leave the organization. So documenting or transferring the knowledge is something which should take place if it has to go from one mind to another

BrainiacV
User Rank
Platinum
Re: Keep telling stories
BrainiacV   9/27/2013 9:10:30 AM
NO RATINGS
Minor edit to the story,

I had to WRITE the program without the OS or hardware.

And what fun it was with only a two page description of the interface card.

Onsite, I didn't have access to any debuggers since it was a realtime environment.  I was really happy that I had taken the time to write all the status results to a ring buffer instead of the more usual read and forget, otherwise I wouldn't have had a clue as to why it was failing, nor documentation to beat over the head of the hardware guy.

I never understood why people couldn't 'fess up to their mistakes. Over the years I've had to figuratively press people up against a wall to get them to admit the fault could have been theirs.  I wasn't looking to place blame, call me silly, I expect problems, but I needed solutions and they would be hiding information which made the problems much harder to fix.

Nancy Golden
User Rank
Platinum
Re: Keep telling stories
Nancy Golden   9/28/2013 12:31:34 AM
It usually takes one event of long and painful troubleshooting for a particular failure mode to stick in one's mind forever. I was building a hall effect tester for high gauss devices and needed an IEEE current source to drive a coil. I have been GPIB programming for years - should not have been a problem to establish communication, although this particular piece of equipment was not by a well known manufacturer and the electronics seemed rather antiquated (which was fine for this particular application) with dip switches that needed to be set manually. I spent hours trying to get my program to talk to the current source but it would not respond. I went through their manual with a fine tooth comb, triple checking all of the dip switch settings. On a whim, I decided to invert the switch settings - ones to zeroes and zeroes to ones. The system started communicating. The company reps wound up taking us out for a steak dinner after I told them about the error in the manual. I learned never to trust documentation when troubleshooting - learn to look outside of the box even if it doesn't necessarily make sense. This is a great article because it reminds us to share these stories - you never know what you might run across.

William K.
User Rank
Platinum
The supervisors personal experience.
William K.   9/28/2013 8:06:28 PM
NO RATINGS
Isn't it great when the managers and supervisors have experience and knowledge, and possibly even insight, into the technology that those underthem are working with? A boss who understands the systems functionality, rather than just understanding spreadsheets? The boss who can pass along useful insights is indeed a good leader, and also somewhat rare.

Larry M
User Rank
Platinum
Re: Keep telling stories
Larry M   9/28/2013 10:32:52 PM
 Twenty years ago I wrote a terminal emulator for an obscure (Beehive) ASCII terminal, working just from the manual. Like many such terminals all data went to the screen unless it was preceded by an escape code: the ESC character followed by a variable length code/parameter block. Also like many of the terminals of that era, each screen position could contain either a character or an attribute. I only had access to the real terminal on low-traffic Sunday mornings.

I defensively added two items to my code
  • A message in the status line when an unrecognized escape code had been received, and identifying the screen.
  • A secret keystroke which replaced the screen contents with the receive buffer ring.

Both of these items paid big dividends. I found out that the application, a Rockwell ACD, was sending malformed escape sequences beginning with ESC ESC from time to time with the unrecognized escape message. The real Beehive terminals treated these as a single ESC and I modified my code to do likewise.

I was informed that the emulator screen scrambled under a heavy traffic load. I managed to get a few minutes during a heavy-traffic weekday and after a few minutes the screen scrambled. I immediately issued the secret keystroke and looked at the buffer. The manual had stated that writing attributes to column 80 of any line was not supported. But the clever Rockwell application programmer had discovered that writing a tab to column 80 jumped the cursor to the next line and relied on that for a proper screen display. I had to insert this undocumented behavior into my emulator which then was rock-solid.

If I hadn't done those two items of defensive programming, it would have taken me hours to find the problems.

a.saji
User Rank
Silver
Re: The supervisors personal experience.
a.saji   9/29/2013 10:21:50 AM
NO RATINGS
Yes indeed being a role model is the success for any business unit. The boss has to lead the way but might not in the field of technology but with the co-workers. 

William K.
User Rank
Platinum
Re: The supervisors personal experience.
William K.   9/29/2013 7:36:00 PM
NO RATINGS
I had made an attempt to be slightly funny about bosses qualifications. Not about top level management, which may not need to have the technical expertise, if they don't attempt to make technical decisions, but about the one-level-up supervisors who really do need to be quite technically competent, in addition to having some management skills. There are lots of them that have neither kind of skills.

BrainiacV
User Rank
Platinum
Re: Keep telling stories
BrainiacV   9/30/2013 10:08:36 AM
NO RATINGS
Nancy, that story reminds me of when I was programming a DigiBoard 80188 communications coprocessor.  The included software either expected Xenix or MS-DOS.  The MS-DOS version emulated a single character I/O, completely ignoring the 256KB of RAM on the card.

In a classic case of miscommunication, the client asked if we could print to more than one printer.  My coding buddy and I had planned to wrote a queued report generator and so we said yes, we'd just add another byte to the queue table to denote printer destination.

We installed the software and the report print queuer printed the report to one printer and after finishing, printed a different report to the second printer. No, said the client, we want both to print simultaneously.  Oops.  The print spooler (as we called it) was not designed to multi-task and we were out of multi-tasker slots in system.

I noted that both printers did print simultaneously at the transition, the printers had 1 KB buffers built into them.

I decided to write a serial buffer program for the DigiBoard and then allocate as much memory as I could spare to the printers.

While writing the code to operate in interrupt mode, I had to set the interrupt enable bits for the interrupt control chip.  It wouldn't work, it wouldn't work, I tried several variations on the coding and finally in desperation, I flipped the bits, and it started working. (Insert snarls and foul language)

When installed, the same report generating code would send the first report to one printer and the second report to the other printer.  There would be a 15 second delay between both printers from the time it took to send the first report into the buffer card and generating the second report.

The client was happy and we patted ourselves on the back for the smoke and mirrors we had used to solve the problem.

Page 1/2  >  >>
Partner Zone
More Blogs from Sherlock Ohms
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Design News Webinar Series
11/19/2014 11:00 a.m. California / 2:00 p.m. New York
11/6/2014 11:00 a.m. California / 2:00 p.m. New York
10/7/2014 8:00 a.m. California / 11:00 a.m. New York
12/11/2014 8:00 a.m. California / 11:00 a.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Dec 1 - 5, An Introduction to Embedded Software Architecture and Design
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Last Archived Class
Sponsored by Littelfuse
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service