Unexpected POSIF behavior

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User10696
Level 4
Level 4
First solution authored
I am using the POSIF in a motor control application. I have got the POSIF.OUT1 connected to a CCU4 slice to measure the speed.
After initialization (motor not running) everything is normal.
While the motor is running, the CCU4 works correctly and I get the correct speed.
If I stop the motor, then the CCU4 generates very fast interrupts at a rate of about 5.5µs. It looks like the CCU4 is seeing the POSIF.OUT1 toggling at this speed. All the registers in the POSIF are stable, so I am not sure why the OUT1 is toggling.

I have seen that if I clear the internal status of the POSIF with the PRUNC.CSM bit, the OUT1 stops toggling.

Is there any reason why this is happening? Is clearing the internal status the correct use of the POSIF?

Any help to understand what is happening would be much appreciated.
0 Likes
7 Replies
ncbs
Moderator
Moderator
Moderator
500 replies posted 50 likes received 250 sign-ins
Hi Adrian,

Yes, PRUNC.CSM bit can be used to clear the internal status ie, resets the state machine of the quadrature decoder and the current status of the Hall sensor and Multi-Channel mode register.

Can you share your project here so that we can have a look into the toggling condition of POSIF.OUT1?

Regards,
Nikhil
0 Likes
User10696
Level 4
Level 4
First solution authored
Hi Nikhil

My project is too big, with a lot of other libraries, to share and it does not run on an evaluation board.
The motor driver part is the standard motor configuration with the POSIF reading 3 hall sensors, a CCU4 slice for the blanking and a CCU4 slice for the speed measurement. The modulation is synchronized with the CCU8 PWM.
The problem occurs when the motor is stopped. In this situation the hall sensor inputs are stable but the CCU8 PWM is running with 0% PWM.
I cannot measure the OUT1 signal from the POSIF, but I see that the CCU4 speed slice is generating interrupts at about 5.5µs intervals, so I assume the OUT1 signal is active.

You might like to correct the XMClib documentation:
The XMC_POSIF_Stop() function clears the CRB and CRM bits, not just the CMB as in the documentation.
0 Likes
ncbs
Moderator
Moderator
Moderator
500 replies posted 50 likes received 250 sign-ins
Hi Adrian,

I suspect that this might be due to vibrations of the motor. Even though the motor is stopped, then vibrations might be caught by the system. This would cause the system to generate glitches.

Can you try enabling the "low pass filter" option present in encoder settings? Check for various clock cycles to see if the glitches are eliminated.


Regards,
Nikhil
0 Likes
ncbs
Moderator
Moderator
Moderator
500 replies posted 50 likes received 250 sign-ins
Hi Adrian,

Thank you for pointing out the error in XMC_POSIF_Stop() documentation. 🙂
XMC_POSIF_Stop() clears both CRB and CSM bits.

Regards,
Nikhil
0 Likes
User10696
Level 4
Level 4
First solution authored
I do not think it is due to vibrations. As the motor is unpowered there is no reason for it to vibrate. The low pass filter is already active. The debugger does not show that any of the register change in the POSIF. It only seems that the OUT1 signal has this problem, there are no modulation update events generated. It is unlikely that vibration would always cause the exactly same frequency.
0 Likes
ncbs
Moderator
Moderator
Moderator
500 replies posted 50 likes received 250 sign-ins
Hi Adrian,

Could you confirm once if the low pass filter has been checked for all available options of the number of clock cycles?

It would be helpful to analyze the error if you could share your minimal project having only the necessary DAVE apps and application code.

Best regards,
Nikhil
0 Likes
User10696
Level 4
Level 4
First solution authored
I have not tried all the filter options, only 16 clock cycles (value 5).

I do not have the time to create a minimal test application, but I could send you my complete test application, But I cannot post it here. The application runs on our own hardware, but it is probably possible to get it to run on the CPU-45 evaluation board if some of the I/O are set to the correct level. We do not use the DAVE Apps.
0 Likes