The V3 XL controllers executed Leap Year one year late. The V4 controllers executed Leap Year, effectively, two years late.

The cause is related to the Real Time clock chip in the hardware. The chip only stores two digits for the year and has a range 00-99. The software adds an offset to the year when reading the chip and subtracts an offset when writing to the chip. In an attempt to utilize the full date range of the chip the software was using an offset based on when the Real Time Clock driver was written. For V3 controllers a 2001 offset was being used. For V4 controllers a 2006 offset was being used. In order for the leap year function within the chip to work correctly the offset year needed to be a leap year.

The solution involved using 2000 for the offset in both cases. However, simply changing the offset would cause the customer issues in the same way that the Leap Day bug did. After an update the date stored in the chip would be interpreted as a date in the past.

The solution also includes attempting to detect controllers that have invalid dates stored in the clock chip. This is done by comparing the Year that XL200 Application was created to the year stored in the clock chip. The year stored in the clock chip should never be older than the application creation date.

V3 controllers that have invalid dates may have a year that is one year older than it should be. If the controller date year is less than the application creation year. The controllers date is updated to the year the application was created.

V4 controllers that have invalid dates will have dates that are 6 years older than it should be. If the controller date year is less than the application creation year, six years is added to the controller date.

In both V3 and V4 controllers, the Set Year setup parameter can no longer be programmed with a year that is older than the year the application was created. This prevents the controller from erroneously detecting an invalid date and trying to correct it.

The detection solution relies on the fact that we have regular releases. Usually new releases occur minimally every few months. If a customer updates to a release, with the bug fix, that is older than one year, we will not be able to detect if their controller has been affected by the leap year bug and we will be unable to automatically correct the date. In addition, if they update to a release that still has the leap year bug, they are re-infecting that controller with the bug.

The 0xx800102FF task error is generated when the controller detects that the free memory chain of the heap is corrupted.

The heap is managed and used by the operating system to allocate memory for display objects and internal operating system needs.

The operating system had bugs in the code that created and deleted OS objects like tasks, counters, mail boxes, ring buffers, semaphores and resources. These OS calls all use heap memory and did not have all of the correct protection mechanisms in place to protect critical sections of the heap manager code.

Once the objects were created, protections were in place to protect these objects when they needed to make use of additional heap memory.

This problem exhibited itself during powerup when most OS objects are created but it could happen at any time. It also happened very repeatable on a Continuous Press Controller. However it only happened due to the happenstance of the timing involved in how the controller power cycles after a memory clear. It could have happened on any controller.

Prior to making improvements for external and internal testing, the Windows simulation was repaired so that the hardware test software can be tested in Windows as much as possible.

The windows simulation compiles and runs. All compiler warnings were repaired.

It is mainly speculation but It appears that the Windows Simulation has not worked since the addition of the DSP. This version of the hardware test evolved from earlier versions for hardware that had no DSP.

The V5 XL200 Hardware has an ARM processor as a replacement for the DSP processor.

The majority of the differences in the sofware(initially) are being isolated to the interface between the 80386EX processor and the coprocessor(DSP or ARM) and the coprocessor software itself.

The V4 hardware test software needed some minor changes to the DSP communication to use the Macros that hide the interface differences between the the DSP and ARM processors. This was done to test that the V4 hardware test still communicated correctly with the DSP before creating the V5 hardware test that will communicate with the ARM processor.

Part of this change was already checked in by mistake.

This test allows the SEROCS hardware, the Fiber optics and SERCOS Chip to be tested by conecting the TX and RX ports together with a cable. It is a test that does not require a drive so that the hardware can be minimally tested using fewer external components.

A new segment was required to store and access the ARM application required for the Rev G and higher 5386 board. This change reads the descripter table and populates the hardware structure so that the 5386 application can access the ARM application and program the ARM if required.

This is no longer the case. This change was removed prior to the software being released. The 5386 Watch Dog signal notifies the ARM chip that the 5386 Watchdog has failed.

The FM31265 will no longer be responsible for the 5386 Watch Dog on Rev G and higher boards. In the Rev H hardware the ARM processor will take over this responsibility with much more control and less 5386 overhead.

These changes are in the Boot Code. In order for these changes to be present the Boot must be updated to V2.05 or Higher.

Most of these changes were made by Jim with some changes made by me. They were made in response to issues with erasing and programming on the Rev H hardware, though there should not have been a difference.

Programming Improvements.

1. Check to see if a word location is already programmed before trying to program it. If it is already programmed correctly it must be due to a communication timeout retry. If it is not programmed correctly or not erased report a programming error back to FlashWizard.
2. Check for programming completion using the method specified in the Flash Part Spec sheet by doing two reads in a row.
3. The commands were doubled, duplicated in the command word with no explanation. This did not match the chip documentation. The Rev C hardware was presumably programming two chips at the same time. The High and Low Bytes may have been going to two different chips. We only have one Flash chip in the Rev D and Higher that operates in a Word Mode. Removed the duplication for clarity.

Erasing Improvements

1. Removed an Unprotect command. This command is not part of the erase process and should never have been in the code.
2. Added an erased test on the first word or each segment as a quick double check of erasure. Not a comprehensive test but simple double check.
3. The same command duplication that was removed from programming was removed in erasing, though erasing already had most of this removed.

The SERCOS Tests already had a single memory test that executed at the start of the functional tests. The Ability to run this test in a loop has now been added.

The 5386 Rev D and higher have a Real Time Clock Chip that also has Persistent Memory. There is a test that tests all of the memory but the test would not run without the controller resetting. The reason for this is that the Watch Dog Timer for the processor is also in this chip. It is not possible to reset the timer while at the same time writing the persistent memory. The code was writing too much data at one time in the test. The solution was to write the data in smaller chunks, allowing time for the operating system to have access to reset the Watch Dog Timer.

The DSP application was rebuilt and tested.

The HWTest DSP shares some common code with the standard XL200 applications and the V5 Hardware test that utilizes an ARM processor instead of the DSP.

Over the years changes have been made to common code for the XL200 applications and more recently due to changes for the ARM processor. The DSP application for Hardware test has not been rebuilt in quite some time. Some stub functions, namely for the ethernet port had to be written in order for the application to compile. Otherwise everything built and seems to function.

The Windows simulation now has the capability to simulate Battery Backed Ram. This allows the simulation to function just like a controller that remembers its memory between startups.

The use of command Line arguments to set the Model and the Switch setting are required. If the two command line arguments are used the simulation will save its memory records and its setups to two binary files, BSSMem.bin and RECMem.bin. The two files are created/updated when the simulation is shutdown in one of the three methods.

1. The main controller display window is closed with the windows close, X, button.
2. The debug window is closed with the windows close, X, button.
3. The debugger Q command is used to shut the simulation down.

These two files are valid, just like the memory in the controller, only for the simulation version, Switch setting and Model that the files.

If the simulation is started with the Switch and Model command line arguments it will look for the two files. If they are present, the simulation will attempt to use them. If the files were created using a different software version, Switch or Model, just like the controller does, the simulation will start up from a cleared memory state. If the same Software, Switch and Model are used the memory will be retained and the simulation will start up in the same state it was in when shutdown.

To allow for multiple simulations to run at the same time with Eclipse we have the port command line. If the port command line is used, the filenames of the files storing memory change slightly. In this case the port number gets incorporated in the file name. For example, if the port number is 1234 the file names will be BSS1234Mem.bin and Rec1234Mem.bin.

A change was made to the hardware on the 5386 Rev H board. The source of the clock feeding the MCLK pin on the SERCOS Chip was changed from SCLK04 to SCLK02. There are several pre-calculated constants that rely on the known speed of MCLK that needed to be recalculated. The controller and Drive will not pass the phase 1 state of the SERCOS phase test run up without the correct constants.

This same change was previously made on the 5226 hardware which uses the same clock speeds and basically the same software. The divisors that were changed in the 5226 are also now changed in the 5386.

These were previously changed in the roll-forming application code when this issue was discovered during the initial testing of the new Rev H hardware. It was assumed the HWTest shared the same source file but that turned out to be an invalid assumption.

In order to process Task Error data, the application (File Name) and the application version must be known. This specifies which map file must be used to interpret the data.

Customers send pictures of the data but are unware of or forget the rest of the information that is required to process it. Now the information will be embedded.

Modified the XL200 Manual Burn In Test to send Pass/Fail reports after each test to the Test Probe, instead of task errors. The Manual Burn In Test now keeps track of how many times each test passes or fails. All messages directed to the Test Probe begin with an identifier character '\x1b' followed by the letter 'b', and end with a newline character '\n'.

During the Port G/H Test, Flash Wizard will now display a 'G' or 'H' above each value in order to reduce confusion about which encoder port is being used.

The XL200 hardware test already tests the communication with the Keyboard Pic when the Pic18F252 Test is selected. If the Pic is communicating with the 386, the Pic Software version will be displayed and the detected components will be displayed. However, if no communication occured, nothing was displayed.

The follwing changes were made to make troubleshooting Keyboard PIC communication easier.

1. If no communication occurs, "Software Version : Not Detected" will be displayed.
2. A menu option "P - Communication Test" has been added.

When the communication test is selected the Software Version will be requested over and over until power is cycled or "Q" is selected. This allows the communication circuit to be tested with a scope.

When troubleshooting XL200 temp chamber failures, it is helpful to know at what temperature the failures happen. The Test Probe Mode in the burnin test allows the XL200 to send burnin test data and the temperature to the Diagnostics website through a Test Probe.

There are several pieces of hardware that get initialized on bootup, knowing which hardware is getting initialized and how far the board is making it through the boot and startup software is very helpfull when troubleshooting bootup issues.

In order, the following text prompts have been added to help in this process.

Start Set_Timer_Values() End Set_Timer_Values() Start Init_SED1355Screen() End Init_SED1355Screen() Start Install_Keyboard_Interrupt() End Install_Keyboard_Interrupt() Start DSP_Load_ProgramData() End DSP_Load_ProgramData()

On a V4 controller the DPS Programm gets loaded by the 386 processor. On a v5 controller, the 386 requests information about and programs the ARM processor only if an update is required. Both of these things are done during DSP_Load_ProgramData.

Several debug prompts were added at the beginning and the end of hardware initializations like the Timer, video, keyboard and DSP (or ARM). If a board fails to boot all the way to the HWTest menu, knowing how far it got and what hardware it was working with last can help narrow down where to look when trying to troubleshoot non working hardware.

Added the same encoder filtering as SCN 4666 to the Hardware test to avoid failing 5387 boards for a known timing issue that has been compensated for.

There are two main changes.

1. The number of Touchscreen/Mouse messages recieved is displayed as Mouse Count in the Keyboard and Touchscreen test results.
2. Five new status bits are displayed with the Keyboard PIC software version. They are Touchscreen, PS/2 Keyboard Reset, PS/2 Mouse Reset, Master PIC, and PS/2 Port Swap. Each status bit results in a Detected or Not Detected status.

The Touch Screen Calibrate option in the hardware test had the capability of causing a divide by zero task error if somehow the exact same X-Coordinate or Y coordinate was sensed for the two points.

The Divide By Zero condition, C0000000 task error, is now prevented with a test on the divisor. An error message will now display instead.

In addition, the Two sensed points, along with their expected position, the X and Y Scale along with the X and Y Offsets are now displayed to help with troubleshooting calibration issues.

The comm port tests report passes and failures. The test alternates between expecting to see its data echoed back or not, depending on the state of the transmitter.

The test reports passes and failures. As long as the UART hardware responds to the XL, generating the appropriate interrupts, normally every other test passes. If all tests fail, it is not possible to tell if it is bcause the 386 is recieving no interrupts or if the appropriate states are not being found in the Interrupt status register in the UART.

Three new counters were added to help determine what is going on in the interrupt. The Number of ISR events are counted. The number of ISR pending (UART says it has an interrupt) are counted. The number of TX Empty interrupts are counted.

These counters will help determine not only if interrups are being recieved by the 386 but is the correct statuses are being reported by the UART hardware within the interrupt handler.

The 5387 board, since V4, has used two 32-bit quadrature encoder counter chips to support the four incremental encoder ports. These parts are obsolete and we have no source for them any longer.

We have found a source for the 12-bit version of these chips. It is apparently a custom build of the 12-bit version that is housed in the 32-bit package. This allows us to use the chip without a board layout change. The only issue is that we have to modify our software to use the 12-bit version. We have to read the encoder often enough so that we never see more than 2048 counts between reads or our math will not work properly to calculate the change between reads.

Through empirical testing we have determined the Max Encoder rate to be 2MHz. If we read the encoder every 100usec, that calculates out to a maximum number of counts equal to 200 per read, well below the 2048 limit.

There will be a new limitation introduced. Any 5387 board with the new 12-bit chip will no longer be compatible with older software versions. The cutoff will be V4.110.0 and V5.110.0. Any software older than this will be incompatible with 5387 boards containing the new chip. Software versions newer than these will work with either version of the chip.

On the old chip we have a Bogus encoder count read of 10,0000 per read. We will be lowering that threshold to 2000 counts per read.

We have modified the Closed Loop Controller code to read at 100usec, even when there are no Open Loop Targets.

The OL gets similar treatment but with a much simpiler change since it was already written to read the encoder more than once per sample.

The version of CodeWarrior that we have been using to compile the DSP software for the Version 4 XL200 controllers will not install on Windows 10, requiring a Windows 7 VM. In addition, it requires a License server that is also nearing End of Life, with no way replacing it. No way of getting a new license that would be valid on the new server.

An new version of CodeWarrior, v8.3 is available from NXP. It requires no license, provided your code is less than 64K. Ours is significanly smaller than that.

The old CodeWarrior project, with some small modifications was imported into the new compiler with some minor changes that are documented in One-Note in a Build Tools section in the XL200 Notebook. Full details can be found there.