CPA fails after successful clock glitch on Authenticated Bootloader

I was able to bypass the MAC authentication on the Fault 1_4 lab using the XMEGA as my target board, however when I perform the CPA attack on the traces which bypassed the authentication it always fails to recover the correct key. I 've tried a ton of different setting for glitch.width, glitch.offset and glitch.ext_offset with different adc.offset values too as suggested by @Alex_Dewar in the following topic Fault 1_4 - Authenticated AES Bootloader - ... no attribute ‘inverse_sbox_output_alt’. I also tried to capture up to 700 traces(obviously those which also bypassed the MAC) and even applied re-synchronization technique(Dynamic Time Wrap {DTW for cwa.preprocessing}), but even the latter doesn’t seem to be the problem.

Has anyone faced similar issues on this lab? If someone could help me on this one I would grateful.
(p.s I 've completed successfully all the CPA attacks in every sca turorial provided, using the XMEGA as target so far, so something seems rather odd and weird here)
Kind regards,
Antonios Tragoudaras

–UPDATE–
Hello everyone I was able to address the issue of CPA attack failing for the traces which bypassed the authentication. So here is my solution if anyone dealt a similar problem:

  1. Trigger on falling edge to skip past authentication operation(scope.adc.basic_mode = “falling_edge”), that way your power traces (which bypassed the MAC authentication) only include the decryption AES rounds, starting straight away with the 1st AES decryption round (
    This is due to how the simple-serial-bootloader works, see bootloader.c :
    trigger_high();
    uint8_t crc = ss_crc(cipher_buf, 0x08 + 0x10);

    // check that MAC is correct
    if (crc != buf[16]) {
    trigger_low();
    return 0x11;
    }
    trigger_low();

    //decrypt
    AES128_ECB_decrypt(buf, key, plaintext);
    )

2)You don’t need scope.adc.samples to be as max as possible (24400 ) since you attacking the inverse sbox output of the first decryption round (hence the last round of encryption). In my case capturing 24400 samples influenced the relation between the Hamming Weight and the Power Consumption negatively (I ran some tests {you can find them in the google drive link down below}, like in lab 4.1 sca101, and figured out that for some reason capturing more samples ruined the linear relationship between power and hamming weight, so that was the caveat). For me setting adc.samples to 7000 solved this shortcoming and the relationship was preserved as linear resulting in a successful CPA attack.
Kind Regard,
Antonios
https://drive.google.com/file/d/1eZx_6XfDv7UT9dxbeIVSjnrPk5ed1u41/view?usp=sharing