RIO unit - Release Notes

Current product info RIO	100 9970 500 .0203
Software in production:	RIO 02.13
Software released date:	2001-01-25
Hardware in production (main RIOC board):	A100C01465.0103
Hardware release date (caused by EO 2001-001):	2001-01-31

NOTES:

• If you upgrade a RIO in field to a software newer than 02.03, you must do a cold start procedure described under 02.10 to activate the watchdog.
  
• RIO 02.12 should be used with AMC 07.09 (07.30) or newer (no compatibility problems, but these AMC softwares handles RIOs better).
  
• RIO 02.13 software must be used if the processor-type is 68HC11E1. ( The "E" family has replaced the "A" family from year 2001.)

Software versions

RIO 02.13 (2001-01-25)

Release : New MCU 68HC11E1 replacing 68HC11A1.

EEPROM and Watchdog enabled on the new MCU.
Software is still compatible with 68HC11A1.

Functional changes

EEPROM protection in the new MCU removed.

The EEPROM and CONFIG are protected by the BPROT register that was not used in 68HC11A1. It is cleared during startup to enable EEPROM and CONFIG writings.

New IAR version used.

This should not affect RIO functionality, but has required some changes in the project files "cstartup.s07" and "lnk6811.xcl".

Errors Corrected

Terminal commands were unavailable after the first one.

Observation: The RIO did not respond to commands after the first one unless a hash (#) was applied in front, but this should not be necessary. Correction: The terminal command function was not prepared for the "LF" character following the "CR", and would take it as the first character of the next command.

Restart time stored as random number

Observation: A RIO that is powered up would store the reset time as a random number (often FFFF) rather than 0000. When the correct time is received from the exchange max. 20 seconds later, this time is stored as reset time. I.e. the problem is just cosmetic, but it may be confusing. Correction: The instructions storing the time were executed before the time had been initialized. Fixed.

RIO 02.12 (1999-01-27)

Release: Standard, bugfixes and minor additions

Recommended used with AMC 07.30 (AMC 07.09) or newer.

Functional Changes

Fast Reset of RCOs when no traffic on data bus

The RIO previously held RCOs active for 3-5 minutes. This may cause problems for applications which have manual backup in case the exchange fails, as there is no indication of exchange failure. This has now been changed so that no data bus activity will reset RCOs after 15 seconds. If bus activity resumes, the exchange is informed, and it will refresh RCOs from it’s internal state.

DIP switches read periodically

It’s now possible to change the switches, and they take effect immediately. Every time a switch is changed, the RIO resets to adjust for the new setting. If a terminal is connected, you can see the device number, protocol version and link mode as part of the reset printout. (If you select point-to-point, the terminal is connected to the exchange port and there will be no immediate response, but when the RIO becomes lonely after 15 seconds it will print the switch settings as a reminder).

Communication statistics logged every hour

One line with error counter plus message counter for own messages and total messages on the bus is printed. Printing one per hour makes it easy to see if communication problems occurs on certain times of the day, and if it’s dependent on the volume of RIO data protocol traffic.

Support for simple logging for the exchange

The data protocol messages STATUS_REPORT and LOG_STRING are received and printed. With AMC 07.30 it’s possible to re-direct the exchange’s log port to external devices like PCs, and the RIO has been used to test this feature and is now able to work as a log device. (.ex_profile.line_monitoring.report1_addr) Properties:

- Requires RIO to be on a multidrop bus, and there should be no normal RIOs on this bus (due to speed requirement for RCI/RCOs)
- Proper time stamp incl. seconds
- Line error messages for stations are printed in a simple format (no details)
- The event handler’s LOG action generates text which is printed here
- Log can contain RCI/RCO activity, or just exchange activity

With AMC08.00 it will be possible to create several call logs, e.g. one for each guard in a parking. You can then place one RIO near each guard!

Message terminal trace for broadcast messages

Added trace of broadcast messages. Note that a RIO bus should normally NOT operate with broadcast active, as it generates a lot of extra messages thus reducing the response time drastically. The addition was done to extend the RIOs bus analyser capacity in general.

PONG message optional parameters adjusted

02.10 had a message format which was re-considered due to some other on-going development work. As these parameters are optional and just human readable for debuging, it was decided to change quickly.

DEVICE_INFO optional parameters added

Preparations for error reporting in AMC 08.00 where the log port’s device up messages may contain device name and software version info. This info is collected by the other RIOs, and can be inspected using the terminal D (show all devices) command. Observe that this is only sent after reset, and if this RIO has been reset after the others, the D command will just show “unknown”.

Changed internal time reference from counter to RTI

The previous softwares used a free-running counter which was re-started by software to measure time. This caused some load-dependent variations. Now the processor’s built-in RealTimeInterrupt is used, giving a very steady reference.

Error dump with backtrace

When a data line error occurs, the last message is dumped along with the error message, thus making it possible to see link details even if the data protocol trace is switched off.

Test commands

Several commands used for software testing which can cause controlled data link errors to see that both the RIO and the exchange behaves correctly.

EEPROM stores trace mode and reset time

The RIO’s microcontroller 68HC11A1 contains EEPROM which becomes active with the coldstart procedure for the watchdog. This is now used to store the protocol trace mode over reset, and it logs the number of resets, plus the time of the last reset.

Errors Corrected

Re-sending of RCI changes worked only for pin 1

Observation: If the RIO sends a RCI change message to the exchange, and this is not ACKed properly, the message is lost after 2 retransmissions/timeout. The RIO stops scanning such an input until it’s armed again from the exchange. The exchange still waits for a RCI change message. Effect: The RCI pin becomes blocked. This error affected all pins except pin 1.
Correction: OK. The RIO will re-send changed RCIs every 10 seconds until the exchange accepts it!

Re-fresh of RCI hardware periodically

Observation: RCIs stuck low. Reported to exchange e.g. when the exchange is reset. Corrected only by hardware resaet of RIO.
Correction: The IIC circuits used as digital inputs are software configurable per pin as either inputs or outputs, by setting bits in an internal register in the circuit (set as inputs by hardware reset.) These direction control bits can be changed by EMC, which causes an input to be stuck low. Now, these registers are initialised by software after system restart, and re-written every minute.

Detection of faulty /non-powered IICB I/O board

Observation: If the IICB board is not powered, the RIO will still work OK on the data communication, and no indication is given in the exchange. Sometimes the RIO will behave strangely, disturbing data communication a lot.
Correction: The software now monitors the IIC bus going to the IICB board, and whenever a change bad/OK occurs, it will inform the exchange. When the board is bad, the RIO will cause device error. When the board becomes OK, AMC will refresh the outputs immediately. The LED will flash slowly red/green.

Retransmit when EOT did not work

Observation: If a message got the response EOT (rather than ACK/NAK/timeout), no further retransmissions would take place.
Correction: All EOTs rather than those following messages decremented the retransmit counter. Fixed.

Communication errors due to high traffic

Observation: Extreme traffic could cause error messages (even if retransmissions lost no messages).
Correction: Tuned internal priorities to skip less important tasks during peak traffic. Added some measurement code to get things under control.

RIO 02.11 (1998-12-23)

Release: Test only

First installation of 02.10 pinpointed some minor problems.
No installations of this version!
Changes/corrections are described under 02.12.

RIO 02.10 (1998-12-14)

Release: Standard, bugfix for noisy multidrop, terminal trace

Large RIO installations still had stability problems.
This version only delivered to Norwegian Post Giro.

Recommended used with AMC 07.30 (AMC 07.09) or newer.

Functional Changes

Terminal user interface for faultfinding

A RIO operated in multidrop RS485 mode can have a PC/terminal connected to the RS232 port. The screen will log data messages on the data line (both to this RIO, and to other RIOs), including timestamp messages from the exchange. If necessary, more detailed data protocol trace can be activated using simple commands on the keyboard (type H for Help):

- P (protocol analysis, 4 levels)
- I (show RCI inputs, pin values + which pins are monitored by exchange)
- O (show RCO outputs)
- S (various board status)
- D (devices on the bus with status)
- = (system actions: “=+” will reset the RIO)
- % (data protocol software testing)
- M (memory inspect for software testing)

See separate RIO Application Note for details.

Setting of ports immediately

In 02.03 it was attempted to correct communication problems by delaying RCO pin setting, thus introducing a pin response delay of 50-100 ms. This has been changed back to immediate setting.

• This means that a RIO RCO changes some 60-80 ms after an exchange RCO.
  
• Best-case timing if used with audio events are:
  

- Connection tone of 350 ms will have RIO RCO the last 250 ms

- Cancel tone of 160 ms will have RIO RCO the last 80 ms

• If more than one RIO RCO is being set by the same event, there is an additional delay of 120 ms per RCO due to data line traffic.
  
• Note that RCIs on the same bus can cause delays of 300 ms or more.
  
• If you need to control audio equipment with RIO RCO, all these RIOs should be on a single audio bus, and no RCIs should be active on this bus. Each exchange event should cause only one output change (RCOs on different buses will be activated nearly simultaneously, though).

The output pins are refreshed every 500 ms, in case electric noise manages to switch of the output latches.

Message RESET_TAKEN is sent to exchange after reset

Earlier, a quick RIO reset would be detected by the exchange after 3 missing PINGs, i.e. 2 minutes.

Now, the RIO informs the exchange that a reset has taken place. The exchange (AMC 07.09/07.30) will reinitialise the RIO immediately, and restore RCO outputs. The RIO is up and running less than one second after the reset.

Message PONG has additional parameters

The terminal function can be used as a data bus analyzer, showing messages to/from all RIOs on the bus. Thus you can get information from all RIOs by connection to one of them.

The PONG messages sent every 40 seconds now has two additional parameters for system debuging:

• Software version.
  

Versions prior to 02.10 will show zero as version.

• Problem counter.
  

Each RIO counts communication problems like checksum errors, NAKs and timeouts for it’s own communication with the exchange. This number will indicate if a certain RIO has particular problems. (For debuging hints, see RIO application note).

LED red/orange/green behavior modified

• General status for communication, where red is worse, and green best

fast blink red	Power on indication and/or no activity on data line. After power on reset of RIO. Implies that the software has started and works OK so far. No communication with the exchange, i.e. data line has no activity with any device (which happens when there are no devices on, or the data wires are broken). After a RESET_DEVICE from the exchange, i.e. device initialization either due to AlphaCom reset, or AlphaCom PONG time-out (2 minutes, this is the worst-case time you have to wait if you power-up a RIO while the exchange is running on AMC older than 07.09 (07.30)). No polling for more than 15 seconds. i.e. normal operation times out due to no activity on data line. After missing multiple PINGs from the exchange (5 min. time-out), indicating AlphaCom device handling high-level problem, or no data line activity (RIO does a software controlled hardware reset)
slow blink red	Some device is being polled, but not this RIO. Means that the data connection is electrically OK, but the exchange does not know this device, or there has been bad communication with this device for more than 2 minutes. This situation can last for some 40 seconds, then the exchange re-tries this RIO again.
slow blink amber	This RIO is being polled by the exchange, but it’s not operational (no RCI/RCO functionality). This will occur with AMC versions older than 07.09 (07.30) if the RIO does a quick reset. There is hope, as the exchange will initialize the RIO after max. 2 minutes.
slow blink green	Normal operation mode After a GET_DEVICE from the exchange, i.e. finalizing of normal initialization from the AlphaCom After a PING from the AlphaCom, indicating that the communication works OK high-level.

• During normal operation:

Indicate message traffic briefly to give an idea about how many messages are sent, and if transmission has problems (orange flashes when green blink).

slow blink amberm	Message in queue to be sent to exchange. Waiting to be polled
steady amber	Message is in being transmitted to the exchange Select / send /ACK sequence in progress.
steady green	Message received successfully ACK received
steady red	Message not received/sent successfully NAK / timeout received/sent

Even if there is no RCI/RCO activity, the RIO will PING/PONG with the exchange every 40 seconds causing LED flashes in amber.

The ACK/NAK indication is reset by the next poll of this device, normally after 50 ms times the number of devices, sometimes later if there is much message traffic.

• During exceptional hardware states:
  

Non-operational hardware is indicated using flashing between red and green.

fast red/green	Special TEST mode used to activate watchdog (see description below)
slow red/green	Hardware self-test has detected a problem: IICB I/O board does not respond, either due to failure, or the power connector is not in place!
random red/green/dark	May occur if the processor does not execute a sensible program, i.e. the EPROM is dead or missing. On older softwares w\o watchdog, electric noise could make the processor run wild.

Note that the terminal feature will present texts indicating the same operational states. The texts will appear every time the LED changes, and also when the “S” (status) command is executed.

Error Corrected

ISO multidrop link layer caused delays and/or lost RCOs/RCIs

Observation: When using several RIOs on a multidrop line, the RCO operations was delayed and/or lost.
Correction: The RIO (and the exchange) handled noisy lines poorly.

• Much stricter character processing.
  

Previously one RIO could recognize an old address as it’s own, and would then transmit in parallel with the next addressed RIO!

• Endless retransmission of RCI_IS_ON/OFF, worked previously only for RCI 1 (might lock up the other pins forever)
  
• Tuned no-response timers, so that retransmissions would take place (inactive RIO would cause a 10 second delay in the exchange before communication progressed again)

Hardware watchdog enabled

Observation: The RIO board could become inoperative (reported as down by the exchange), and would never reset by itself. The LED would typically flicker red/green randomly. Also, power-on reset sometimes did not work if the RIO was powered by the exchange as this voltage comes up slowly due to high load.
Correction: The processor 68HC11 comes from factory with the internal COP function disabled. It must be enabled in a special test mode:

• Power down the RIO, open it and insert new software.
  
• Connect the two test pins found close to the processor.
  
• Power up the board. The LED will blink red/green.
  
• Power down the board, and remove test pin connection.
  
• Close the RIO mechanics again. Power up, now in operational mode.
  

The terminal function S (status) will show if the Watchdog is active or not.

RIO 02.03 (1998-04-30)

Release: Standard, performance upgrade AMC/RIO

Customers complained about delays and lost events.
Recommended used with AMC 07.03 (AMC 06.06) or newer.

Functional Changes

LED red/orange/green behavior tuned

Steady amber (normal power on indication)	After power on reset of RIO. Amber implies that the software has started and works OK so far. No communication with the exchange has yet taken place. After a RESET_DEVICE from the exchange, i.e. device initialization either due to AlphaCom reset, or AlphaCom PONG time-out (2 minutes, this is the worst-case time you have to wait if you power-up a RIO while the exchange is running) After missing PING from the exchange (2 min. time-out), indicating AlphaCom device handling high-level problem (missing ping causes RIO restart)
slow blink green (normal operation indication)	After a GET_DEVICE from the exchange, i.e. finalizing of normal initialization from the AlphaCom After POLL or SELECT from the exchange, indicating that communication works OK low-level After a PING from the AlphaCom, indicating that the communication works OK high-level. RIO answers PONG.
slow blink amber	Missing POLL from exchange, i.e. low level problem with communication; either no communication at all, or the AlphaCom ignores this RIO’s address.
fast blink amber	Missing activity on communication line in the middle of a message transfer
fast blink red	Fatal error internally in RIO communication
flashing, red and green	No software, i.e. EPROM missing, or contents is garbage.

Setting of ports every 100 ms

Previously port pins were set immediately when a set/reset pin command arrived, causing disturbances for the data link receiver. Now, hardware ports are set (and refreshed) simultaneously every 100 ms.

Errors Corrected

ISO multidrop link layer caused delays and/or lost RCOs

Observation: When using several RIOs on a multidrop line, the RCO operations was delayed and/or lost.
Correction: Fixed several bugs in the link software. This, together with improvements in AMC 07.03 (alt. 06.06), gives a much better RCO handling.

RIO 02.02 (1997-08-04)

Release: Standard, AMC 06.xx data protocol upgrade

The data protocol was changed and published as part of AMC 06.

Functional Changes

Data protocol upgrade

The new data protocol format was introduced (extra hop counter).
To avoid version problems between AMC and RIO in the market, the new RIO is backward compatible. New protocol is activated by setting DIP switch 8 ON.

RIO 01.01 (1996-05-01)

Release: Standard, first

Delivered with AMC 05.xx

Known problems

“Unexpected EOT” when missing devices

Observation: This error message sometimes occurs if the exchange polls a non-existing device, times out, and then immediately after tries to send a message to some other device. It seems to be a timer problem in the AlphaCom.

RCI sent twice ocasionally

Observation: Sometimes the mesage “RCI_IS_OFF” is sent two times in rapid succession. This does not disturb the communication.

Hardware Versions

Only one version used.

(But observe that some special projects has been using the RIOC processor board named “GPU - general processing unit”, and the GPU is a revised RIOC board!)

Known problems

RIO does not start after Power-on reset

Due to the non-operational watchdog in software versions 02.03 and older, the RIO board sometimes would not start after power-on. This occurred frequently if the RIO was powered directly from the exchange.

It’s possible to improve the situation considerably by changing a resistor to a zener. There is a Technical Bulletin describing the modification.

(Note that RIOs delivered after the Bulletin was released still were delivered from factory WITHOUT the modification!).

RCOs are active after Power-on reset

RCOs on the IICB connector board does not have a hardware reset signal. The outputs very often go ON after reset, and stays ON until the software switches them off several hundred milliseconds later.