Dwt_setxtaltrim is causing TX problem

Recently I upgraded my decadriver code to the latest release from dw1000_api_rev2p14_stsw. I found the successful packet pass rate is degraded. Finally, it turns out to be related to the following code:
if(!(DWT_DW_WAKE_UP & config))
{
// XTAL trim value is set in OTP for DW1000 module and EVK/TREK boards but that might not be the case in a custom design
if ((otp_xtaltrim_and_rev & 0x1F) == 0) // A value of 0 means that the crystal has not been trimmed
{
otp_xtaltrim_and_rev = FS_XTALT_MIDRANGE ; // Set to mid-range if no calibration value inside
}
// Configure XTAL trim
dwt_setxtaltrim((uint8)otp_xtaltrim_and_rev);
}

The code set the XTAL trim value, where it is not there in the old release. So I have the following four testing:

  1. TX side: Remove the trim, RX side: Remove the trim. Send 100 packet, and count the successful RX packet count: the number is 100, 100, 99, 100, 100 (The test is carried out 5 times)
  2. TX side: Keep the trim, RX side: Remove the trim. The number is 16, 6, 15, 14, 10.
  3. TX side: Keep the trim, RX side: Keep the trim. The number is 15, 10, 12, 16, 22.
  4. TX side: Remove the trim, RX side: Keep the trim. The number is 99, 98,97, 100,96.

So it seems once the TX side call dwt_setxtaltrim((uint8)otp_xtaltrim_and_rev), the performance will be degraded. And the best result is got when both RX/TX side removed the XTAL trim code.
The XTAL freq are not calibrated on both the TX and RX boards, I lack the spectrum analyzer now. But I still expect the similar result should be got on test case 1 and 3, and similar result on test 2 and 4.
Now I focus on functionality of the product. So there is not much requirement on the location accuracy yet. So I hope I can skip the calibration steps which I can’t carry out now.