TMDSHVPSFBKIT: Base Board Replacement

Hi Sam,

I'm going to move this out of the motor solutions forum and into the general C2000 32-bit MCU forum, as this kit does not pertain specifically to InstaSPIN.

Sean

Thank you Sean

-Sam

Team,

More info from the customer regarding the reason behind the necessary repair/replacement:

We have 2 kits.

Both kits were working initially with the load connected and original firmware in the flash (I checked them several time for a short period).

Power got converted from 400 to 12 V and a serial communication to PC worked. All the experiments were held in PCMC mode, the default one.

 

Then one controller board was converted into the version for loading the code from CCS (v6), the cap, resistor and the jumper…

 

Kit #1.

As per documentation the code started working on the controller powered by external 11VDC supply. After supplying ~400V I saw 12V output.

However, ~10 mins later 12V disappeared, than serial communication to PC stopped.

2^nd controller board with pre-flashed code neither worked. External supply 11VDC dropped to 2-3V.

Aux power module on the base board did not generate 12V anymore.

 

Kit #2.

Both controller boards, pre-flashed and loadable were working. I tried to double check my steps with the documentation this time.

2^nd controller board loaded from CCS v6 was running 10-15 mins and producing the output 12V on the load resistor.

Then the output voltage started flickering and eventually dropped to zero.

Both controllers work (LED blinking when connected over UART to the GUI app, the GUI updates the info from the controller).

The only thing is that the base board does not produce 12VDC output anymore. GUI app showing Vout as 0.xxx V. Fault Flag is set (1.000).

 

So far, base boards are out. Controller boards seem OK.

 

Hopefully this info leads us to a decision between repair/replace.

Thank you for the support,

-Sam

Hrishi,

Thank you for your support!!

-Sam

Hrishi Nene said:

There are two possibilities: either the code did not port correctly (wrong include paths, aggressive code optimization, etc.) or some human/experimental errors occurred during testing.

Please, explain:

- Does the base board have any protection against loosing the control by the controller board?

- What typical events on the controller board can damage the base board? Missing ISR? Stopping at a break point by CCS? Any common things done wrong by users?

- Can the main board be used for reference design and troubleshooting of the custom-made controller? If yes, what are general precautions when working with the board?

Thank you

Hi Aleksandr,

Please see my answers below. 

- Does the base board have any protection against loosing the control by the controller board?

HN: There is over-current protection that uses the on-chip analog comparator, which should work even if the controller board somehow loses control (unless the controller supply is lost).

- What typical events on the controller board can damage the base board? Missing ISR? Stopping at a break point by CCS? Any common things done wrong by users?

HN: This is a little tough to answer. If the default code is run without any changes in control, switching or system clock frequencies, I do not expect things to go wrong. This solution is heavily dependent on code execution timing inside the ISR. So if the above frequencies and or trigger points are changed that might affect the behavior drastically. This kit has been in the market for ~5-6 years now and I haven't come across similar scenarios.

- Can the main board be used for reference design and troubleshooting of the custom-made controller? If yes, what are general precautions when working with the board?

HN: I believe the question is whether the HVPSFBKIT board can be used as reference for designing a custom board, correct? If so, yes most definitely. The main thing to pay attention to is the timing in triggering the ISR and also for code execution inside the ISR. As I mentioned in reply to your other post features on our newer devices greatly help simplify this process.

I hope this helps.

Hrishi 

Hrishi,

> There is over-current protection that uses the on-chip analog comparator, which should work even
> if the controller board somehow loses control (unless the controller supply is lost).

Let me bring an exact example. When using the GUI app for serial communication it may eventually send the code of 65 over serial port (performing "Find Comport" action) to the MCU which causing the code going out of control (registered commands there are 0..12, 65 is far away). The controller goes out of its mind. May this cause any damage to the base board?

And there's something that confuses me in the user guide. It suggests to probe PWM waveforms. However I can't locate any TP's exposing them. Should I solder some wires over the controller board to scope it or any alternative exists? That would help to control if ePWM ISR is still running and generates the waveform.

I am just about precautions to avoid any further wrong step which may damage the base board of the kit.

Thank you,

Alex.