SWOCTRL register update failure. Application is BLDC motor Control

[Qazi]

Earlier, I was using the following configuration to update the SWOCTRL. With this configuration SYNCHOM is set to 0. I faced a problem that the commutation continues to work for 1 hour to 1 day but during this time period, their used to come a time where the BLDC motor used to be stopped. After debugging, I found out that the OUTMASK gets updated but SWOCTRL used to be on the old value. 
Could you shed some light on what could have gone wrong.
Our understanding was that maybe the clock was on the boundary when OUTMASK is updated and SWOCTRL is left behind but it still doesnt explain that with next clock boundary, it should also get updated, but it didn't.

// Configuration for Register Value Update
const ftm_user_config_t  flexTimer_pwm_InitConfig =
    {
        {
            true,   // Software trigger state
            false,  // Hardware trigger 1 state
            false,  // Hardware trigger 2 state
            false,  // Hardware trigger 3 state
            true, // Max loading point state
            false, // Min loading point state
            FTM_SYSTEM_CLOCK, // Update mode for INVCTRL register
            FTM_SYSTEM_CLOCK, // Update mode for SWOCTRL register
            FTM_SYSTEM_CLOCK, // Update mode for OUTMASK register
            FTM_SYSTEM_CLOCK, // Update mode for CNTIN register
            true, // Automatic clear of the trigger
            FTM_WAIT_LOADING_POINTS, //  Synchronization point
        },
        FTM_MODE_EDGE_ALIGNED_PWM, //!< Mode of operation for FTM
        FTM_CLOCK_DIVID_BY_128, // FTM clock prescaler
        FTM_CLOCK_SOURCE_SYSTEMCLK,   // FTM clock source
        FTM_BDM_MODE_00, // FTM debug mode
        false, // Interrupt state
        true // Initialization trigger
    };

// ISR for BLDC commutaiton
uint8_t private_hal_mc_actuate_set_pwm_mask(uint8_t ui8OutMask, uint16_t ui16SwCtrl)
  {
      FTM_DRV_MaskOutputChannels(3/*INST_FLEXTIMER_PWM3*/, ui8OutMask, false);
      FTM3->SWOCTRL = ui16SwCtrl;
  	return 1;
  }

[Qazi]

Hi @danielmartynek ,
The reason I wasn't using enhanced PWM synchronization was the lack of information on my part. And currently I am using the Software trigger option with PWM enhanced Snchronization and its working fine.
I am using S32k148. The reason I am asking this question here is that I dont understand what was happening, even though I know the reccomendation but technically what was happening didn't make sense. I checked for memory leak and stuff to make sure the register was not being over written but it wasn't.
The only pattern I found out was that the value of OUTMASK was updated, but the value of SWOCTRL was not updated.
So it wasnt that it had any INVALID value, it had a value which was set to it at the previous encoder pulse.
And the crazy part was that I had IF condtion just outside the function I mentioned here to check whether the SWOCTRL register doesnt has the value which I have set into it, but it nevert went in. so it appeared to me that the value is set in the shadow buffer but the main register naver took the value and afterwards the shadow register had the old value.
Please let me know if you need any further information from my side.
Thank you,
Qazi

[danielmartynek]

Hi @Qazi,

I will need to escalate this to the design team, as I am unable to explain the observed behavior based on the available information, and there do not appear to be any similar reported cases.

I would like to clarify a few points though.

Have you tried changing the order in which the registers are written? Why the driver API is used for updating one register while the other is written directly? 

I would like to better understand your description of the software check. As I understand it, you write to the register and immediately read it back within a condition (RM, section 3.4.1 “Read-after-write sequence and required serialization of memory operations”) - the read operation return the recently written value.
However, it is not clear what exactly you mean by stating that “afterwards the shadow register had the old value.” Can you please elaborate?

Thank you,

BR, Daniel

[Qazi]

Hi @Daniel,
Thank you again for reply and sorry for not replying earlier.
I think we have found the problem. There was a place where SWOCTRL was being written apart from the ISR routine. And if the ISR comes specifically when SWOCTRL was being writen, since its not an atomic operation, the value was being set to the old value.

Again thank you so much for your time.

[danielmartynek · Accepted solution]

Hi @Qazi,

Which S32K1xx derivative are you using?
Could you please verify the SYNCONF register to ensure it is not being unintentionally overwritten?
Also, is there a reason you are not using enhanced synchronization?
According to the Reference Manual (see section 47.8, Initialization Procedure), the use of enhanced synchronization is recommended.

BR, Daniel