MCSPTR2A5775E - Motor not running after flashing software

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCSPTR2A5775E - Motor not running after flashing software

Jump to solution
1,086 Views
MarcoD
Contributor II

Hello,

I just received the MCSPTR2A5775E kit. I tested the boards when received it, and the motor was spinning toggling the switch and pressing the buttons.

The second step I tried was to upload the software, I have S32DS Version: 2.1  (Build id: 190624), I've installed AMMCLIB_v1.1.23.

Following the steps here, I used the software provided here,I have imported the project, created a new debug configuration for OpenSDA and flashed.

At this point, the motor does the alignment phase, but the software seems to get stuck: it never goes out of this while:

/* wait till SW Resolver is properly started */
while(resolver_states.state < 4){
    FMSTR_Poll();
}

I also tried the FreeMaster interface, and I don't see any change in the rotor angle, even if I spin the disk manually. Moreover, if I press any button after 3 seconds from toggling the switch (to allow the alignment phase to end), the motor starts to spin and then I am getting an overcurrent error. To me, it seems that there is no position feedback from the resolver.

Did you encounter this problem before?

 

One extra note: From FreeMaster, I am able to spin the motor using the "Scalar Control", which doesn't use the position sensor, confirming my theory.

Running1.PNGRunning2.PNGRunning3.PNGRunning4.PNG

I have also checked the resolver signals adding them to the FreeMaster page, and the SDADC seem to work fine:

Running5.PNG

Thank you,

Marco

 

 

Tags (1)
0 Kudos
1 Solution
1,054 Views
MarcoD
Contributor II

SOLVED!

 

NXP support pointed out that I didn't have the jumper on J122 between pins 28 and 29.

The latest sw version requires that link in order to get the resolver position, while the previous one didn't.

 

I disregarded that part of the manual (Chapter 3.4) because it was working out of the box without it, and later I forgot about it.

View solution in original post

0 Kudos
2 Replies
998 Views
MarcoD
Contributor II

I also believe there is a bug in the "While" I mentioned, where the code is waiting for the resolver state to change above 4; however I believe this state is never updated. A tell for this behaviour is the fact that my phase currents had always some DC offset; in fact the offset is compensated just after this while.

I simply added a call to the function that reads the resolver state within the while loop, and now the code continues and the phase currents don't have DC offset anymore, as visible below

 

 

 

/* wait till SW Resolver is properly started */ 
while(resolver_states.state < 4) { 
   FMSTR_Poll(); 
   fs_etpu_resolver_get_states(&resolver_instance, &resolver_states); //Fix to exit loop when resolver is aligned
}

 

 

 

 

CurrentOK.PNG

 

 

Tags (1)
0 Kudos
1,055 Views
MarcoD
Contributor II

SOLVED!

 

NXP support pointed out that I didn't have the jumper on J122 between pins 28 and 29.

The latest sw version requires that link in order to get the resolver position, while the previous one didn't.

 

I disregarded that part of the manual (Chapter 3.4) because it was working out of the box without it, and later I forgot about it.

0 Kudos