Lessons Learned |
VxWorks tNetTask is not a TaskTwo (2) SMSC LAN91C111 devices are utilized on a single Printed Circuit Board (PCB) for two Ethernet ports. The software employs the VxWorks RTOS and the LAN91C111 software driver provided by SMSC. There is an issue in that when the Ethernet cable of one of the devices is reconnected (or sometimes when disconnected), the task that performs the lengthy Auto-Negotiation process for that device is executed and prevents tasks of the other device from executing. The netJobAdd() function call below resides in the section of the lan91c111Int() function that processes the INT_MDINT interrupt: netJobAdd ((FUNCPTR)AdapterReset, (int)pDrvCtrl,0,0,0,0);Virtually every combination of the following methods have been employed in an effort to force the task of the Auto-Negotiate process (of the AdapterReset function) to be reprioritized and/or rescheduled and/or delayed to allow tasks of the other device to execute:
The following observations have been made while monitoring the LAN91C111 Interrupt pin and General Purpose Output Port pin of both devices on the oscilloscope before, while, and after executing the Auto-Negotiate process within the associated task:
It is worthy to note that a simple taskDelay(x) in the task which eventually performs the Auto-Negotiate process will prevent tasks of the other device from executing for the time that the task of the Auto-Negotiate process is delayed. The oscilloscope photos that follow show three signals of two LAN91C111 devices (#1 and #2) of two Ethernet Channels (#1 and #2). The three signals are acquired when the Ethernet cable of Channel #2 is reconnected which causes the Auto-Negotiation process to run. A brief description of each signal follows:
The photo below shows the signals that result when tNetTask calls AdapterReset(). Note that when the Auto-Negotiate process for device #2 is performed (when BOTTOM signal is low), the interrupts for device #1 (TOP signal) ARE NOT serviced and the sendto() and recvfrom() function calls for device #1 (MIDDLE signal) ARE NOT called:
The solution is to have the LAN91C111 ISR do a netJobAdd() of a function which then does a taskSpawn() of the AdapterReset() function. The photo below shows the signals that result when tNetTask calls a function which spawns a task for AdapterReset(). Note that when the Auto-Negotiate process for device #2 is performed (when BOTTOM signal is low), the interrupts for device #1 (TOP signal) ARE serviced and the sendto() and recvfrom() function calls for device #1 (MIDDLE signal) ARE called:
The required software changes to the module lan91c111End.c of the SMSC LAN91C111 software driver follow:
|
80386EX Random Divide By Zero ExceptionOne of the following erroneous conditions was randomly occurring after applying power to each of three separate and identical 80386EX boards:
The solution to the problem is that the 80386EX Slave PIC must be initialized even if that internal Slave is not to be used. The Intel386 EX EMBEDDED MICROPROCESSOR USER'S MANUAL, Chapter 9 INTERRUPT CONTROL UNIT, describes the 82C259A Master and Slave Peripheral Interrupt Controllers (PIC) residing within the 80386EX microprocessor. This manual describes the Master PIC Initialization Command Word 3 (ICW3) register bit S2 as follows:
When the Internal Slave PIC is not to be used, one might expect that by clearing bit S2 in the Master PIC ICW3 register, the Slave will be disabled and thus there is no need to initialize the Slave PIC. However, the NOTE above the description of the Master PIC ICW3 register states the following: NOTE Since the internal slave is cascaded from the master's IR2 signal, you must set the S2 bit.Therefore, a more accurate description for the Master PIC ICW3 S2 bit value of zero would be: 0 = Internal slave is not cascaded from the master's IR2 signalSince the 80386EX Master PIC IR2 signal is supposedly hardwired to the Slave PIC INT signal and no option exists to disconnect it, the accurate description for the Master PIC ICW3 S2 bit would be: S2 Set this bit to guarantee proper device operationIt has been observed that if one incorrectly assumes that clearing the MASTER PIC ICW3 S2 bit will cause the Slave PIC to be ignored, Divide By 0 exceptions and other random interrupts will activate randomly during and instead of a valid Master PIC interrupt. To guarantee proper operation of the 80386EX, it is critical that the Master PIC ICW3 S2 bit be set and the Slave PIC be fully initialized by writing to the Slave ICW1, ICW2, ICW3, and ICW4 registers and then disable all Slave PIC interrupts by setting all bits in the Slave PIC OCW1 register to a 1. One may question why Intel did not give default values for the above registers, as they did for the PIC Port 3 Configuration Register (P3CFG) and the PIC Interrupt Configuration Register (INTCFG), to initialize and disable the 80386EX Master and Slave PICs. The required assembly code to properly initialize and disable the 80386EX internal Master and Slave PICs follows:
One may question why Intel did not give default values for the above registers, as they did for the PIC Port 3 Configuration Register (P3CFG) and the PIC Interrupt Configuration Register (INTCFG), to initialize and disable the 80386EX Master and Slave PICs.
|
AOL Browser Accepts 'name' as 'id' for getElementById()
It was learned that when the America Online (AOL) browser, which utilizes Microsoft Internet
Explorer, is processing a HyperText Markup Language (HTML) file that resides on the Internet,
the browser will accept a 'name' specified in the HTML code as: name="..." and then
successfully execute the JavaScript function document.getElementById() using that 'name'
instead of an 'id' as required by document.getElementById() and specified in HTML code as:
id="...".
Note that when Internet Explorer is executed directly (i.e. not by the AOL browser), a 'name'
will be rejected for document.getElementById().
This is true when Internet Explorer is processing a file that resides on the Internet or on
the computer hard drive.
The HTML code to zoom in and out of the image below improperly employs
the HTML code:
The HTML code to zoom in and out of the image below properly employs
the HTML code:
Proof of where the JavaScript code fails is now demonstrated.
In the JavaScript ZoomTest() function below, an alert() function is called after each line of
JavaScript code that performs the zoom process.
This is done to report each line of zoom code that completes execution.
If a line of code should fail to execute due to an error, the code that follows the error will
not be executed and the following message will not be reported: var origw=new Array()
The HTML code to zoom in and out of the image below improperly employs name="..." as: <form>
When executed by the AOL browser, the last message reported when any button is clicked should be:
|
Software Engineering Disasters
A Software Engineering Disaster is exposed at 2 minutes and 17 seconds into the video below.
See from Youtube if not available above |
Lost
The duplication of the identifier R (for ROZO) was there for everyone to see on the FMS: But the pilot "assumed" the one he was to fly to was the closest and thus at the top of the list. Such known issues with duplicates need to be emphasized so they can be recognized by incompetent and careless pilots in a rush.
See from Youtube if not available above |
Cutting Corners
The pilots gave 100% effort right up to the very end, even flying the plane upside down, but it was hopeless.
See from Youtube if not available above |
Web site questions/comments? Contact: TDB Consulting