When programming an XL200, FlashWizard attempts to read the application, version, bitcodes and a file name out of the controller. It uses this to compare against the file that is being programmed to see if an authorization code is required.

There was an issue if any of the data lengths for these fields were zero. In most cases they shouldn't be, unless engineering has been working on a controller or locations of fields are getting remapped. The boot code doesn't like to be asked to read 0 bytes of memory. It failed to respond and Flashwizard stopped the Flash Programming process, preventing the controller from being programmed.

FlashWizard has been modified to treat this condition as if no Application is in memory. It may require an authorization code but at least the controller will be programmable.

See SCN 4164.

The universal programmer uses the JTAG port to program the boot on 5386 boards and to perform other tests.

The software in the universal programmer was not erasing both boot segments in flash for any 5386 board rev greater than D. D and higher use the same flash erase algorithm. Prior to erasing flash, FlashWizard was modified to lie to the programmer, telling it that these boards are Rev D boards.

After a recent windows update the Stop Bits setting began to default to 1.5 rather than the setting stored in the registry. This was easy to miss when opening the screen.

In addition, the code operated perfectly when debugging the application. It only failed when running an EXE configured for Release. The issue was resolved by explicity initializing the bound variable rather than relying on the UpdateData method to do it in the OnInitDialog method of the window.

Prior to this change the Primary and Universal Programmer ports shared the same Parity, Stop Bit and Data Bits Setting. A change to one affected the other.

Technically, if we allow them to be set, they should be independent to avoid confusion. This has been resolved.