TCM320C ENOCEAN, TCM320C Datasheet - Page 2

• Manufacturer Part Number: TCM320C
• Description: MODULE SOC RF TXRX W/8051 MCU
• Manufacturer: ENOCEAN
• Series: -r

Specifications of TCM320C

• Frequency: 315MHz
• Data Rate - Maximum: 125kbps
• Modulation Or Protocol: ASK
• Applications: General Purpose
• Power - Output: 5dBm
• Sensitivity: -98dBm
• Voltage - Supply: 2.6 V ~ 3.3 V
• Current - Receiving: 33mA
• Current - Transmitting: 24mA
• Data Interface: PCB, Through Hole
• Memory Size: 32kB Flash, 2kB RAM
• Antenna Connector: On-Board, Wire Whip
• Operating Temperature: -25°C ~ 85°C
• Package / Case: Module
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant
• Other names: 1084-1000; S3033-K320

UART hangs up (transmitting) or looses bytes (receiving) during full duplex
operation
Description
Under certain circumstances it is possible that an UART transmit or receive interrupt is lost. This
only happens during full duplex (simultaneous transmitting and receiving) serial operation.
The transmit and receive interrupt flags are bit-addressable in the 8051 SFR (special function
register) space and are located in the same 8 bit register. From software perspective clearing of
an interrupt flag is an atomic operation, but on the hardware side, a read-modify-write occurs
(since the register is a single 8-bit unit). The problem now occurs when a new transmit/receive
interrupt occurs (respective interrupt flag is set) between the read and write cycles.
There are two possible scenarios resulting in two different effects:
1. During clearing of a receive interrupt flag the transmit interrupt flag is set (TI occurs within 2
clock cycles after an RI=0 instruction). Then the transmit interrupt flag is accidental cleared and
transmitting of further bytes will hangs up.
2. During clearing of a transmit interrupt flag the receive interrupt flag is set (RI occurs within 2
clock cycles after an TI=0 instruction). Then the receive interrupt flag is accidental cleared and
the received byte will be lost.
Workaround
1. Use half duplex communication
If possible use half duplex communication. This will completely avoid the behaviour described
above.
2. Avoid hanging up of transmitting bytes by adding a timeout mechanism
The Dolphin API (>= V1.4.0.0) has implemented a timeout mechanism using the system sched-
uler (timer interrupt). With every 1 ms tick the scheduler proves if UART transmission is ongoing
and whether the communication was locked or not. If it was locked the scheduler unlocks this
manually and the error log counter ERR_UART_TX_INT_LOST is incremented.
This will result in an inter-byte delay between 1 ms (best case) and 4 ms (worst case) of the
transmitted bytes.
If the Application is using the API System log feature, it is possible to detect this unlock events
(for more info read EO3000I_API.chm->Error Diagnostic->System Log).
Note:
3. Handling of lost received bytes
There is no workaround completely avoiding loosing a received byte.
The Dolphin API (>= V1.4.0.0) has implemented a mechanism where a newly received byte is
also detected under the error condition if the new byte has a different value than the previous
one (does not work if the bytes are identical). In such case the ERR_UART_RX_INT_LOST is
incremented.
If the Application is using the API System log feature, it is possible to detect this rescue events
(for more info read EO3000I_API.chm->Error Diagnostic->System Log).
Additionally using of a protocol, e.g. ESP2 (using the Serial Telegram Checksum) or ESP3 (using
the Packet CRC8), allows to detect lost bytes and to request and resend the data.
Status Sheet – TCM 320 DA
STATUS SHEET
This API workaround does not apply to ultra low power applications where the scheduler
is not running!
Page 2/2