Eclipse Community Forums: Eclipse Titan » problems with little-edian dword in RAW codec

Home » Eclipse Projects » Eclipse Titan » problems with little-edian dword in RAW codec

problems with little-edian dword in RAW codec [message #1801864]

Mon, 28 January 2019 11:02

Eclipse User

I'm currently trying to express a 32bit little-endian bitfield using the TITAN RAW codec and I simply cannot get it to work. I must have tried all permutations of FIELDORDER, BITORDER and BYTEORDER without success.

The full module source is available at http://git.osmocom.org/titan.TestPorts.USB/tree/src/CCID_Types.ttcn

Maybe somebody can provide a quick help?

The data in question is simply a 32bit DWORD in little-endian byte order. It contains reserved bits in the upper 30 bits, and two defined bits as the two LSB.

module CCID_Types {

type bitstring BIT30 length(30) with { variant "FIELDLENGTH(30)" };

type record CCID_Protocols {
        BIT30                   RFU,
        boolean                 protocol_t1,
        boolean                 protocol_t0
};



} with { encode "RAW"; variant "FIELDORDER(msb)" }

I always get something like

    dwProtocools := {
        RFU := '000000000000000000000000000011'B,
        protocol_t1 := false,
        protocol_t0 := false
    },

This seems to suggest that the bit-order is correct, but somehow the field-order isn't - despite the entire module having set FIELDORDER(msb) in the definition above.

If I decode the entire 32bit value not as CCID_Protocols but using the u32le_t definition below, it works. But of course I don't get the individual bits decoded as booleans, as intended.

type integer u32le_t (0..4294967295) with { variant "unsigned 32 bit" variant "BYTEORDER(first)" };

I'm trying similar constructs with a variety of data types, and it seems to always work when the bitfield is < 8 bits (e.g. 5 MSB RFU, then 3 bits as individual bools) but it seems to consistently fail whenever the record is encoded over more than one byte.

Thanks in advance for your help.

Re: problems with little-edian dword in RAW codec [message #1801867 is a reply to message #1801864]

Mon, 28 January 2019 12:50

Eclipse User

The RAW encoder works on octets. The FIELDORDER specifies how the fields or the part of the fields are organized within the octet, not the order of the fields within the received data

How the encoded data looks like?

x x x x x x t1 t0
x x x x x x x  x
x x x x x x x  x
x x x x x x x  x

If yes, just change the order of the fields in the record.
type record CCID_Protocols {
boolean protocol_t0,
boolean protocol_t1,
BIT30 RFU
} with {variant "FIELDORDER(lsb)"};

Or:

t0 t1 x x x x x x
x x x x x x x  x
x x x x x x x  x
x x x x x x x  x

If yes, just change the order of the fields in the record.
type record CCID_Protocols {
boolean protocol_t0,
boolean protocol_t1,
BIT30 RFU
} with {variant "FIELDORDER(msb)"};

Re: problems with little-edian dword in RAW codec [message #1801892 is a reply to message #1801867]

Tue, 29 January 2019 04:57

Eclipse User

Thanks for your quick response and for presenting a work-around for the problem.

I intentionally did not want to re-order the fields in the record to keep the order of fields the same way as people would "normally" write it if they were writing (or looking at) a "C struct" definition. This way it's also much easier for a human being to compare the definition in TTCN-3 and the definition in C when writing related code.

I was under the impression that the various *ORDER attributes of the RAW codec would provide me with that flexibility, but it appears I was mistaken. Thanks for clarifying it.

Re: problems with little-edian dword in RAW codec [message #1801893 is a reply to message #1801892]

Tue, 29 January 2019 05:05

Eclipse User

The order of the fields within record, ser, union is also the part of the encoding instruction.

The TITAN always try to decode the fields in the given order. That behavior can be used for decoding of union as well.

Previous Topic:	Eclipse Titan
Next Topic:	Issue with ETSI ITS Conformance Suite execution

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 16:32:20 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter