diff options
| author | Vadim Yanitskiy <axilirator@gmail.com> | 2019-05-17 01:08:08 +0700 |
|---|---|---|
| committer | Vadim Yanitskiy <axilirator@gmail.com> | 2019-05-17 01:08:22 +0700 |
| commit | c78ea26f219ff4d8b0a8fce08a17168dedf2f157 (patch) | |
| tree | 007c92f0a9f24accd9127fcd8921ae6d2499ed09 /library/PCUIF_Types.ttcn | |
| parent | a2d59c6e6efa1fa979aa5e1cd61a9eb21a775cb6 (diff) | |
library/PCUIF_Types.ttcn: add explicit ALIGN(left) attribute
In the documentation of Eclipse Titan compiler before [1] it was clearly
stated that if the length of the actual value can be determined and it
is less than the specified FIELDLENGTH, the remaining bits / bytes will
be padded with zeros. The attribute ALIGN specifies the sequence of the
actual value and the padding within the encoded field:
Attribute syntax: ALIGN(<parameter>);
Parameters allowed: left, right;
Default value: 'right'.
Since [1], the default value is:
'left' for octetstrings, 'right' for all other types.
[1] https://github.com/eclipse/titan.core/commit/3cbafbd31d5f79049afbf69f8dcba0b94cbf20b2
In the most 'BTS_Tests.TC_pcu_*', including both 'TC_pcu_data_req_agch'
and 'TC_pcu_data_req_imm_ass_pch' we do pass the payload of length 23
bytes to ts_PCUIF_DATA_REQ(), what is less than the actual field length
(162 bytes). Thus when using titan.core <= 6.5.3, the payload appears
at the end of the buffer on the BTS side, so it reads 23 zero-bytes
from the beginning and does transmit them.
Let's explicitly add ALIGN(left) to field 'data' of 'PCUIF_data', so
the alignment would be done correctly, as expected by the BTS. Let's
also drop 'OCT162' type, as it doesn't make sense outside the
message definition.
This change makes the following test cases pass:
- 'TC_pcu_data_req_agch' and
- 'TC_pcu_data_req_imm_ass_pch'.
Change-Id: Ic4f358e5053e30e0dd7be8b6ac9c1d86cf9d8065
Diffstat (limited to 'library/PCUIF_Types.ttcn')
| -rw-r--r-- | library/PCUIF_Types.ttcn | 10 |
1 files changed, 4 insertions, 6 deletions
diff --git a/library/PCUIF_Types.ttcn b/library/PCUIF_Types.ttcn index 17adbd1c..750e0b4d 100644 --- a/library/PCUIF_Types.ttcn +++ b/library/PCUIF_Types.ttcn @@ -67,12 +67,10 @@ type record PCUIF_txt_ind { PCUIF_Text text } with { variant "" }; -type octetstring OCT162 length(162) with { variant "FIELDLENGTH(162)" }; - type record PCUIF_data { PCUIF_Sapi sapi, uint8_t len, - OCT162 data, + octetstring data length(162), uint32_t fn, uint16_t arfcn, uint8_t trx_nr, @@ -82,7 +80,7 @@ type record PCUIF_data { uint16_t ber10k, int16_t ta_offs_qbits, int16_t lqual_cb -} with { variant "" }; +} with { variant (data) "FIELDLENGTH(162), ALIGN(left)" }; type record PCUIF_data_cnf_dt { PCUIF_Sapi sapi, @@ -373,7 +371,7 @@ template (value) PCUIF_Message ts_PCUIF_DATA_IND(template (value) uint8_t bts_nr template (value) uint8_t ts_nr, template (value) uint8_t block_nr, template (value) PCUIF_Sapi sapi, - template (value) OCT162 data, + template (value) octetstring data, template (value) uint32_t fn, template (value) uint16_t arfcn, template (value) int8_t rssi := -80, @@ -405,7 +403,7 @@ template PCUIF_Message tr_PCUIF_DATA_IND(template uint8_t bts_nr := ?, template uint8_t ts_nr := ?, template uint8_t block_nr := ?, template PCUIF_Sapi sapi := ?, - template OCT162 data := ?) := { + template octetstring data := ?) := { msg_type := PCU_IF_MSG_DATA_IND, bts_nr := bts_nr, spare := ?, |