Release Notes for UPT- and CVT- FIRMWARE
=============================================================
 (UPT = user programmable terminal, like UPT-515, CANopen
  CVT = can view terminal, for example MKT-View, CANdb ! )

 Author: Wolfgang Buescher (Software Development Engineer, MKT)
 File  : <WoBu3>\cbproj\uptwin1\firmware\relnotes.htm
 Revision: 2015-04-20 (ISO8601 format : YYYY-MM-DD)

 Only available in English language !
   Even if there were translations into other languages,
   only *THIS* document is imperative.
   Do NOT make copies of this file, and 
   do NOT copy parts of this document into other files.



 Diese Datei ist -bis auf diesen Absatz- nur in englischer Sprache verfügbar !

   Fertigen Sie bitte KEINE Kopien dieser Datei an, 
   und kopieren Sie KEINE Teile dieser Datei in andere Dokumente ! 

   Eine Kurzanleitung zum Firmware-Update beim MKT-View III
   in deutscher Sprache finden Sie hier .

   Eine Übersicht der Firmware-Artikelnummern mit einem 
   Auszug aus der Firmware-Revisions-Historie finden Sie
   in der Readme-Datei im Firmware-Verzeichnis.

   Einen Auszug aus der Entwicklunggeschichte des Programmiertools
   finden Sie im 'Update-Checker' auf der MKT-Webseite:
   www.mkt-sys.de/check4update/ctptwin1.htm
The information in this file only apply to the firmware files which must be kept in the same directory. Usually, you will find this file after installing or updating the TERMINAL PROGRAMMING TOOL in the 'firmware' directory.

Everything else can be regarded as an invalid, and most likely NO MORE UP-TO-DATE COPY. Check MKT's website for an update.

Some general information about available firmware variants, and how to update the firmware in your device, can be found in the readme-file in the firmware directory.
The above 'readme' also contains an excerpt from the firmware revision history.
A guide how to update the terminal's firmware is in the same directory in the file fwupdate.htm . In that document you will also find the password which must be entered in the programming tool to upload the firmware via serial port or CAN-bus.

A table with the features of all programmable terminals can be found in the feature matrix (part of the manual).



Known problems with recent firmware releases
---------------------------------------------------------------
(ordered by firmware article number and device)


art11045  (UPT-515 mit Digital-I/O-Erweiterung)
---------------------------------------------------------------
 - No known problems.
 - No message rate limits because no handling of CAN messages
   in an interrupt.


art11046  (UPT-515 with real time clock)
---------------------------------------------------------------
 - No known problems.
 - No message rate limits because no handling of CAN messages
   in an interrupt.


art11047  (UPT-167 with large black&white - display)
---------------------------------------------------------------
 - Relatively slow display due to lack of CPU power and large display:
   Screen update rate may drop to 3 frames per second,
   depending on the complexity of the programmed display page.
 - No message rate limits because no handling of CAN messages
   in an interrupt.


art11048  (UPT-167 with colour display)
---------------------------------------------------------------
 - Really slow display due to lack of CPU power and large display:
   Screen update rate may drop to 2 frames per second,
   depending on the complexity of the programmed display page.
 - No message rate limits because no handling of CAN messages
   in an interrupt.


art11080  (MKT-View, IPE-View, PCB "MTG320 V1.0 24MHz", 1 Flash)
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - Reception and decoding of MULTIPLEXED messages impossible.
 - No known functional problems.
 - The PCB is no longer in production, 
     THIS FIRMWARE IS NO LONGER SUPPORTED !


art11085  (MKT-View, IPE-View, PCB "MTG320 V1.0", 2 Flash chips)
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - Reception and decoding of MULTIPLEXED messages impossible.
 - No known functional problems.
 - The PCB is no longer in production, 
     THIS FIRMWARE IS NO LONGER SUPPORTED !


art11086  (MKT-View, IPE-View, PCB "MTG320 V1.1 24MHz")
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - Limited message rate as explained in the revision history,
    explained under Limited Message Rate due to CAN interrupts .
 - The PCB is no longer in production, 
   but the firmware was still supported in 2004-05.
 - Maximum specified message rate for MULTIPLEXED messages,
    received by the terminal application (after ID filtering):
     2000 msgs/second (added from both buses).



art11087  (MKT-View "+", PCB: "MTG320 V1.1 - V1.3, 40MHz)
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - Limited message rate as explained in the revision history,
    explained under Limited Message Rate due to CAN interrupts .
 - Maximum peak message rate, tolerable for fractions of a second
    until the RAM buffers are filled:
     10000 msgs/second (added from both buses).
 - Maximum specified message rate received by the APPLICATION:
     2000 msgs/second (added from both buses).



art11089  ("MKT-View + LOGGER" , PCB: "MTG320 V1.1 - V1.3, 40MHz)
---------------------------------------------------------------
 - If the serial port is occupied by the application, it may be 
   necessary to enter programming mode manually because the programming
   tool cannot detect the baudrate of the serial port automatically.
 - IMPORTANT: DO NOT TRY TO TRANSFER THE APPLICATION VIA CAN-BUS
   WITHOUT DISCONNECTING ALL OTHER CAN-NODES ON THE NETWORK !
   The tool shows a warning before entering programming mode via CAN,
    see chapter Potentially Hazardous Application-transfer via CAN.
 - timing problems with CERTAIN(!) combinations of display and
   CPU board, causing incorrect display when accessing the CF card.
   ( If this happens in your terminal, please let us know ! ! )
 - total size for all BITMAP graphic limited to 16kByte due to CPU
   ( changed to 64 kByte in ART11089_BETA.HEX, December 2004 )
 - Limited APPLICATION message rate
    as explained under Limited Message Rate due to CAN interrupts .
 - Limited LOGGED message rate 
    as explained under Different Message Rate Limits for logging .
 - Peak message rate, tolerable for fractions of a second
    until the RAM buffers are filled:
     10000 msgs/second (added from both buses).
 - Maximum specified message rate for the APPLICATION (no logging):
     2000 msgs/second (added from both buses).
 - Maximum specified message rate for all LOGGED messages,
    averaged, added from both buses, with suitable Compact Flash Card:
     1500 msgs/second (added from both buses).
 - Even less performance if the trigger signals are MULTIPLEXED !
    (no values can be specified for this. We strongly recommend
     you do *NOT* use multiplexed signals in the trigger conditions)
 - Signals travelling on the CAN-Bus as 32-bit FLOATING POINT NUMBERS
    are treated as IEEE-Floats ("Vector Standard") since 2007-11-26 .
	64-bit floats can only be logged, but not displayed . 


art11126  ( UPT-320 with 16-bit CPU, CANopen, PCB: MTG320 V1.3)
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - DO NOT CONFUSE THIS FIRMWARE WITH THE "MKT-VIEW"-Firmware !
 - Hardware is identic with MKT-View-PLUS
 - First beta release was available in August 2004 
 - Officially called UPT-320 to avoid confusion with the MKT-View-
   firmware:
     art11087 is for CANdb-defined networks (automotive) ,
     art11126 is for CANopen-networks only  (automation) !
 

art11127  ( UPT-320 with 16-bit CPU, CANopen, PCB: MTG320 V1.3)
---------------------------------------------------------------
 - total size for all BITMAP graphic limited to 16kByte due to CPU
 - similar like art11126, but with file system for CF card

art11314  ( MKT-View II  Prototypes, Board V1.0 and V1.1 )
---------------------------------------------------------------
 - detection of ERROR FRAMES may slow down the display
   when many thousand CAN-error-interrupts per second 
   are fired (this is a 'known issue' but not a real bug)
 - support for CAN3 and CAN4 (using CAN-via-UDP) not tested   
 - CAN-Logger, CAN-Snooper, GPS decoder, GPS-logger not fully tested
 - File system (FAT32 *without* LFN) / SDHC not fully tested
 - CAN-termination resistors will be DISABLED during power-off
 - modified the trigger conditions for the CAN logger, 
   rendering logger configuration files INCOMPATIBLE with older
   devices (like MKT-View "plus")
 - Firmware compiled before 2009-02-02 didn't support CAN-transmit
   on CAN2 ( command ctx2 corrected in later releases )
 - Firmware compiled after 2009-02-05 requires an UNLOCK CODE
   for features like CAN-Logger, CAN-Snooper, GPS, RGB-LEDs, Audio, etc
 - Modified display-backlight-timeout.
 - more in c:\cproj\arm_view\Notizen\MKTview2_Release_Notes.txt

 
art11351 (UPT-128 with 32-bit CPU, CANopen, PCB: "UPT128B V1.0")
----------------------------------------------------------------
 - 2010-12-21: Problem with PDO-mapped digital inputs fixed
 - 2010-12-21: Added script language support, not fully tested yet 

art11353 (UPT-320 with 32-bit CPU, CANopen, PCB: "UPT320B V1.0")
-----------------------------------------------------------------
 - 2010-12-21: Problem with PDO-mapped digital inputs fixed
 - 2010-12-21: Added script language support, not fully tested yet 
 - 2010-12-22: Modified display-backlight-timeout. 

art11359 (CDP-MIL 320, with LPC1788 / Cortex-M3)
-------------------------------------------------------------------
 - 2013-03-26: Firmware updates should only be performed via file transfer,
               not sector-wise (via CAN-Bus-Tester). Reason: see file transfer .
 
art11362 (UPT-320 "I/O" with 32-bit CPU, CANopen, PCB: "UPT320-IO")
-------------------------------------------------------------------
 - 2010-12-21: Problem with PDO-mapped digital inputs fixed
 - 2010-12-21: Added script language support, as in many similar devices
 - 2010-12-22: Modified display-backlight-timeout. 
 
 
art11392 (MKT-View III 'CANdb', with Cortex-CPU )
art11393 (MKT-View III 'CANopen', with Cortex-CPU )
-------------------------------------------------------------------
 - 2014-02-20: If a firmware update is interrupted (cable- or power fail, etc),
               the CPU (LPC1788) may not restart after a power off/on cycle
               because without a valid interrupt vector table, the CPU
               (like most other Cortex-M devices) refuses to boot 
               from internal FLASH. In such a condition, the device can be
               'rescued' via the serial port(!) with NXP's 'FlashMagic'
               as explained in Readme_MKTview3.pdf.
 - 2013-08-01: SDRAM timing problem at high temperatures (programmable delay lines).
               Fixed by reprogramming a part of the external memory controller
               every 5 seconds, based on the LPC1788's 'EMCCAL' register.
               If you experience stability problems at temperatures above 60°C,
               make sure the device firmware is not older than 2013-08-01 !
 - 2013-03-26: Firmware updates should only be performed via file transfer,
               not sector-wise (via CAN-Bus-Tester). Reason: see file transfer .


art11532 (MKT-View IV, with Cortex-M4 CPU)
-------------------------------------------------------------------
  - 2014-11-21 Due to a silicon bug in the LPC4357 chip revision '-',
               the second CAN port is not reliable. This problem will 
               disappear (hopefully) as soon as LPC4357 chip revision 'A'
               is available. 
               NXP announced the bug-fixed chips for January 2015.
               Details in the Errata sheet, "CAN.1" 
                ( registers in the CAN controller are overwritten
                  when accessing other 'on-chip peripherals'. )
               Crude bugfix (in the MKT-View IV firmware):
                After each 'potentially dangerous write access'
                to I2C, MCPWM, I2S, DAC, ADC, the firmware tries to
                'rescue' certain values in the CAN controller.
                Especially at the SECOND CAN INTERFACE, this may cause
                occasional loss of received CAN messages, because
                the (inevitable) access to the first I2C-bus (I2C0)
                disabled interrupts from the 2nd CAN controller.
               
             + Ethernet interface needs to be fixed, it's non-functional
               in the prototype boards (MKT-View IV board V1.0).


art11542  (HBG 22 'V2' with LPC1788, 'CANdb' variant)
---------------------------------------------------------------
 - No known problems.


art11543  (HBG 22 'V2' with LPC1788, 'CANopen' variant)
---------------------------------------------------------------
 - No known problems.


Explanations
======================================================================


2010-12-22: Modified the display-backlight-timeout
----------------------------------------------------------------------
There is an extra item for the 'low power' backlight intensity in the BIOS setup menu. Value "zero" (=off) would be invisible on this particular TFT display, so "zero" intensity is automatically replaced with a "low but visible backlight intensity".
If you really want to turn *OFF* the backlight after a certain time of 'operator non-activity', set the LOW BRIGHTNESS value (in the system menu) to ONE, not ZERO ! 

2006-02-16: Potentially Hazardous Application-transfer via CAN
----------------------------------------------------------------------
   In Februrary 2006, the option to transfer the application from PC
   to terminal via CAN-bus was added, now also for devices without
   CANopen protocol. To achieve this, two "special" CAN-Identifiers
   are used during program transfer. They are (by default):
     CAN-ID 0x07F0 from PC to Terminal
     CAN-ID 0x07F1 from Terminal to PC
   TO AVOID SEVERE CAN-COLLISIONS WHICH MAY EVEN STOP THE NETWORK,
   DISCONNECT EVERYTHING ELSE FROM THE BUS (except PC and terminal)
   BEFORE ENTERING "TRANSFER MODE VIA CAN" !
   The programming tool shows a warning, and also shows which CAN-
   Identifiers will be used for the transfer, but it is the respon-
   sibility of the operator to make sure "nothing else"
   is connected to the bus.


2003-12-04: Limited Message Rate due to CAN interrupts 
----------------------------------------------------------------------
   In December 2003, the handling of CAN messages was completely 
   re-written. We are now using an interrupt-driven buffer 
   for all received messages, received from all buses.
   With the exception of the logger firmware, hardware-filtering
   of the received CAN messages is still used.
   Effect: Under normal conditions, no multiplexed messages
           can get lost as long as the buffer with 1024 entries
           does not overflow. 
           Short bursts of messages at full bus load (at 500kBit/sec)
           can be tolerated, even with the same CAN identifiers.
   Downside: This causes additional CPU load from the CAN interrupt.
           If this message rate is exceeded, the screen update 
           gets significantly slower due to heavy load from 
           the CAN interrupt.
   Previously, when terminals with CANdb functionality couldn't 
   handle multiplexed messages, it was possible to POLL the hardware
   receive buffers in the main loop, to evaluate only the latest
   received message. 



2003-11-24: Different Message Rates Limits for the Logger
----------------------------------------------------------------------
     (quite difficult, only for experts..)
   The Logger firmware uses two stages of buffering, due to
   limitations of the used CPU (max 16-kByte objects).
   The first buffer is filled by the CAN interrupt, using
   a "fast but relatively small" buffer with a maximum
   capacity of 800 entries. All received messages must
   pass through this buffer; the LOGGED as well as the
   DISPLAYED messages.
   Every ten milliseconds, the entries in the first buffer
   are processed in a timer interrupt and copied into a
   second buffer, which is "large but not very fast".
   The second buffer is only used for LOGGED messages,
   it had a maximum capacity of 6000 entries in the first
   working firmware. This buffer is used as for the
   pretrigger function, but it is also used to bring the
   received messages into the format which will be 
   written on the Flash Memory Card.
   So what's the point ? There are *three* different
   "message rate limits" to observe when using the
   terminal firmware with the CAN Logger option:
    - First limit: Speed of the CAN interrupt handler.
       In the "MKT-View +", the CAN interrupt handler
       is fast enough for 100% bus load at 500 kBit/sec
       on **ONE** of the two buses.
       This can be as high as 15000 messages per second,
       if the CAN messages are short.
       But, after 800 messages received in a burst,
       the first buffer may be full so there is another
       limit..
    - Second limit: Speed of the Timer interrupt routine.
       Every 10 milliseconds, the timer interrupt handler
       processes as many CAN messages in the 1st buffer
       as possible.
       In the "MKT View +", this can be up to 4000
       messages per second.
       The 10-ms-routine also does the trigger handling,
       which varies greatly in complexity and speed !
    - Third limit: Speed of the file writing routine.
       As often as possible, and as soon as there are
       more than 512 bytes of data in the "large" buffer,
       the firmware will write another DATA SECTOR to
       the Compact Flash Memory card. The speed of the
       disk file access depends on the model of the card.
       We were told that under certain conditions, especially
       LARGE (!) memory card may only be able to write 600
       messages (a 16 byte, including timestamp+ID) per second.
       In own tests with two 512 MByte cards from SANDISK
       we could see no difference between a standard card
       and a "SanDisk ULTRA 512MB" card (used for cameras).
       Both cards were able to record up to 2000 messages/second,
       but note that these are no SPECIFIED (or GUARANTEED)
       values !
  The figures given above are based on measurements with
  an MKT-View "+".  The newer MKT-View II (with 32-bit CPU)
  uses a different storage medium (SD or SDHC instead of CF card),
  but also here, the max message rate depends very much on
  the memory card. Netto logging rates up to 2000 messages/second
  were never a problem, even with the slowest SD memory card.
  Larger message rates may work, but have not been tested so far.

  
  
 2013-03-26: Recommended firmware update via file transfer
----------------------------------------------------------------------
  This only applies to devices with LPC1788, and similar Cortex-M3 CPUs,
  as used in the 'MKT-View III' and 'CDP-MIL 320'. 
  Technical background:
     The LPC1788 cannot boot directly from external FLASH, 
     only from INTERNAL FLASH. But the internal FLASH is always occupied
     by the 'normal firmware' - it's much too precious (and small) to be
     wasted for the 'firmware bootloader', which resides in EXTERNAL FLASH.
     Thus if the firmware update is interrupted before the 'new' firmware 
     has been flashed completely,
     the device can only be rescued with NXP's FlashMagic.
  Cure / Workaround / Suggestion: 

(Note: It the above links are broken because someone changed the structure 
of the MKT website, you will find most of those files 
in the UPT programming tool's "help" folder)
  
   
<End of file RELNOTES.HTM>