Did you close the device or is it still open? If you are not explicitly setting the TRUSTFENCE_DEK_PATH Yocto variable to "0", then the boot artifacts are not only signed, but encrypted as well. Look at the local.conf, are you setting it to a predefined path? If so there's no doubt that the boot is failing because, on an open device, encrypted artifacts cannot be booted properly. This explains the CRC error because, before running the bootscript, U-Boot parses information from its header and verifies that the script's CRC is correct. This obviously fails when the script is encrypted.
To verify this, on the development machine, open the boot.scr file in the tmp/deploy/images/<platform> directory of the Yocto project using a plain text editor. If you see nothing but meaningless binary, then it's encrypted.
To disable encryption and only have the project sign the artifacts so that they can be booted on an open device, add the following to the local.conf:
TRUSTFENCE_DEK_PATH = "0"
Then, before flashing the generated boot partition to the device, try opening the boot.scr file again. You will see some binary at the beginning of the file (this is the header parsed by U-Boot), then a perfectly legible U-Boot script, and finally, the binary CST/signature at the end of it.
Also, in case you run into more problems after this, rootfs encryption is also enabled by default, so booting the rootfs as you would normally do after flashing it will not work. You can either:
Follow the extra steps in the documentation to generate a SWU package and flash the encrypted rootfs: https://www.digi.com/resources/documentation/digidocs/embedded/dey/2.6/cc6/yocto-trustfence_t_secure-boot-set-up#program-the-encrypted-rootfs
Disable rootfs encryption entirely by adding TRUSTFENCE_INITRAMFS_IMAGE = "" to local.conf