There are two problems here. The first one is the compiler crash you reported. The second one concerns issues with the provided ACN grammar.

1. Compiler Crash

To illustrate the problem, I've included a simplified part of the grammar you sent (some fields were removed for readability):

CfdpPDU ::= SEQUENCE {
   pdu-header PDUHeader,
   payload OCTET STRING (CONTAINING PayloadData)
}

PayloadData ::= CHOICE {
   file-directive FileDirectiveType,
   file-data FileDataType
}

FileDataType ::= SEQUENCE {
   file-data-pdu FileDataPDU
}

CfdpPDU [] {
   pdu-header [] {
      pdu-type                  PDUType [encoding pos-int, size 1],
      pdu-data-field-length     PDUDataFieldLength [encoding pos-int, size 16]
   },
   payload [size pdu-header.pdu-data-field-length] {
      file-directive            [present-when pdu-header.pdu-type == 0],
      file-data                 <pdu-header.pdu-data-field-length> [present-when pdu-header.pdu-type == 1]
   }
}

FileDataType <PDUDataFieldLength: pdu-data-field-length> [] {
   file-data-pdu <pdu-data-field-length> []
}

In this example:

• The ACN grammar provides definitions for CfdpPDU and FileDataType, but not for PayloadData.
• The ACN specification for PayloadData is embedded directly within the ACN definition of CfdpPDU. This embedded specification applies only within the context of CfdpPDU.

However, since PayloadData is an ASN.1 type assignment and there is no explicit ACN definition provided, the compiler assumes a default ACN specification for the PayloadData type, as follows:

PayloadData [] {
   file-directive [],
   file-data []
}

This default specification is problematic because the file-data field references FileDataType, which has ACN parameters. References to types with ACN parameters must explicitly include arguments in the format <arg1, arg2, ...>. However, as this default specification is automatically generated by the compiler (rather than provided by the user), it bypasses typical user error checks. The crash occurs when the compiler later attempts to generate the encoding function for PayloadData but cannot proceed due to missing required arguments for the file-data field.

Temporary Solution

I modified the compiler so that, instead of crashing, it now generates an error message indicating that the file-data field requires arguments. The error message looks like this:

dataview.asn:185:13: error: ACN parameters and arguments do not match. Expected 1 parameter but got 0 arguments. Reftype is FileDataType

However, note that the error message references the ASN.1 file (dataview.asn:185:13), not the ACN grammar. This might be confusing because the issue is ACN-related, not ASN.1. This is a temporary measure until we devise a better way to handle this scenario.

2. ACN Grammar Issues

To resolve the above issue, I modified the ACN grammar as follows:

CfdpPDU [] {
   pdu-header [] {
      version                                 NULL [pattern '000'B],
      pdu-type                                PDUType [encoding pos-int, size 1],
      direction                               [encoding pos-int, size 1],
      transmission-mode                       [encoding pos-int, size 1],
      crc-flag                                [encoding pos-int, size 1],
      large-file-flag                         NULL [pattern '0'B],
      pdu-payload-length                      INTEGER [encoding pos-int, size 16], -- Added to specify payload length explicitly
      pdu-data-field-length                   PDUDataFieldLength [encoding pos-int, size 16],
      segmentation-control                    NULL [pattern '0'B],
      length-of-entity-ids                    LengthOfEntityIds [encoding pos-int, size 3], -- TODO: Add mapping-function 
      segment-metadata-flag                   NULL [pattern '0'B],
      length-of-transaction-sequence-number   LengthOfTransactionSequenceNumber [encoding pos-int, size 3], -- TODO: Add mapping-function 
      source-entity-id                        [size length-of-entity-ids],
      transaction-sequence-number             [size length-of-transaction-sequence-number],
      destination-entity-id                   [size length-of-entity-ids]
   },
   payload <pdu-header.pdu-data-field-length, pdu-header.pdu-type> [size pdu-header.pdu-payload-length]
}

PayloadData <PDUDataFieldLength: pdu-data-field-length, PDUType: pdu-type>[] {
  file-directive [present-when pdu-type == 0],
  file-data      <pdu-data-field-length> [present-when pdu-type == 1]
}

The main change here is that the PayloadData type assignment now explicitly includes ACN parameters, and the payload field in CfdpPDU provides the required arguments using the <arg1, arg2, ...> syntax. This prevents the compiler from generating a default ACN specification for PayloadData and avoids the error described above.

During testing, I encountered another runtime encoding issue. After debugging, I realized that the field pdu-header.pdu-data-field-length was mistakenly used as the length determinant for both payload and file-data in FileDataPDU. However, these two packets differ: payload always contains additional data (e.g., the segment-offset field, which is 3 bytes long). To resolve this, I introduced a new ACN field, pdu-header.pdu-payload-length, explicitly specifying the payload length.

However, encoding still fails at runtime. The cause is that the pdu-header.pdu-data-field-length field is still used as the length determinant for file-data in FileDataPDU. Because PayloadData is a CHOICE type, pdu-header.pdu-data-field-length only receives a valid value when the file-data field is selected. The automatically generated test cases cover all fields, including file-directive, where pdu-header.pdu-data-field-length remains unset, leading to runtime encoding failures.

To avoid this issue, you should modify the ASN.1/ACN grammar to ensure that the pdu-header.pdu-data-field-length field is always set to a valid value, regardless of the selected choice.

Additionally, please ensure you update your compiler to the latest version 4.6.0.4 to apply these improvements and resolve the reported issues.