The Asterix CAT 034 message uses byteOrder bigEndian but bit order leastSignificantBitFirst for numbers that span bytes. For example they describe an 11-bit integer in this way:
In this picture you can see they are numbering the bits from the right, leastSignificantBitFirst starting from 1. But the COUNTER field spans all of Octet 3, but also includes the least significant 3 bits of Octet 2. In those least significant 3 bits are the most significant (numerically) 3 bits of the 11 bit COUNTER integer, so this is bigEndian byte order, but leastSignificantBitFirst bit order.
The DFDL standard does not allow this combination of bitOrder and byteOrder, as there was no known documented use case at the time the new bitOrder property was added to the DFDL specification. It was however, proposed that it was likely this combination would be needed, and here is a well-documented use case.
So Daffodil should lift this restriction and allow this combination.
The workaround in the mean time is to parse this counter as two separate integers, one 3 bits and one 8 bits, and use an inputValueCalc expression to compute a field with the expected value.