There are missing serial ports (COM ports) when viewing the 'SerialPortService' under 'PlatformServices' in a station. Some or all COM ports will be missing. Local serial ports and/or serial ports of the attached modules do not function.
TAC IA Series
I/A Series AX Jace 8000
This could show up for several reasons.
- This was found during an upgrade to Niagara 4.2.
- It was also experienced when converting a Jace8000 running N4.2 (or lower N4 version) to AX.
- This can occur with a new out of the box J8000 to AX conversion if you do not first commission the Jace8000 to Niagara 4.4 or above before converting to AX.
All of these problems are due to older version USBbinary files not being properly updated during commissioning. The LON option module (side-car) might stop communicating on the LON trunk due to the same binary file issue.
This can be fixed via serial shell; either by direct connecting with a mini-USB cable or via ssh after it is enabled from the Platform Administration view. It is recommended that PuTTY.exe be downloaded and used as the terminal program to access the shell.
The directions below are CASE-sensitive and must be entered exactly as shown. We recommend that you do not type these commands, but rather use copy-and-paste to avoid typographical errors.
This is especially true of the usbSerialNumber itself -- it is case-SENSITIVE.
By default, PuTTY.exe uses mouse-left-click-drag-and-highlight as an automatic shortcut for copy. Mouse-right-click is the automatic shortcut for paste.
Once logged in type:
- Display the USB serial number(s)
sh [hit enter]
$ ls /etc/usb [this will display the USB serial number(s), if nothing displays see the note* at the bottom]
85091090FPGGS41 [this is an example serial number]
- Display the available binary files
$ ls -Rp /sys/images/usb [this will display the available binary files]
Note: You could also see '_r05' instead of '_r04'. If this is your result, make sure to update using the line below.
The USB ports unavailable is due to the 'Tridium485-2_r04.bin' (or Tridium485-2_r05.bin) file was not written to the USB serial number file. This can be corrected by updating the USB serial number file with the correct binary file using the statement below. Make sure to replace the X in the statement with the highest number binary found in 'STEP 2' above.
$ echo /sys/images/usb/vid03eb/pid2425/Tridium485-2_r0X.bin > /etc/usb/<usbSerialNumber>
- Update the binary file
Using the example serial number and USB binary file found in STEP 2:
$ echo /sys/images/usb/vid03eb/pid2425/Tridium485-2_r05.bin > /etc/usb/85091090FPGGS41
Make sure to use the serial number found when 'ls /etc/usb' was called. If there is more than one serial number found, write the command multiple times, once for each serial number found.
Also, make sure to use the highest USB binary file number found. Currently r05 is the highest number. If '_r05' is returned as the available USB binary file, make sure to use '_r05' when updating the USB serial number.
After a reboot, check the SerialPortService to confirm the ports are restored.
*Note: if no usb serial number was found using ls /etc/usb another method would be to call for the slog by typing:
An error would have been logged here during the last startup and will display the serial number; example output:
Oct 10 13:42:06 1 6 0 serusb_is_device_supported: Device 2 on bus 0 unrecognized. Using CDC-ACM Class
Oct 10 13:42:07 4 11111 0 error opening /etc/usb/85091090FPGGS41 rc=-1
In addition to the symptoms listed above, the inability to communicate with the LON option module may cause the any of the following messages in the Serial Shell and/or the Platform Administration System Logs:
error opening /etc/usb/<serial number here> rc=-1
U50Read returned unknown rc = 8!!!
io_write failed ldvRC=7, length=<various numbers of bytes>
The Station will most likely show that the LON network is up, but the LON devices are down. The device fault cause may show "unable to write" or something similar.