• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 82 subscribers
  • Views 763 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UCC5870QEVM-045: Configure UCC5870QEVM-045 via SPI at initialization on SIMULINK

Jaerm
Prodigy 30 points

Part Number: UCC5870QEVM-045
Other Parts Discussed in Thread: LAUNCHXL-F28379D, , UCC5870-Q1, UCC5881-Q1

Hi,

I am currently working on an ACIM motor control PoC based on SIMULINK and the LaunchPad LAUNCHXL-F28379D, like this :

PC+SIMULINK ↔ LaunchPad with 0/+3V PWM outputs → UCC5870QEVM-045 to get -8/+15V outputs → Inverter with six +15V IGBT gates → triphased ACIM

In SIMULINK, before doing anything else, I must first configure the UCC5870QEVM-045 module properly at startup with the right data frames in the right order.

It looks like it would be too complex to do that using the SPI blocks from C2000 Microcontroller Blockset from scratch, since there are almost no example except a CCS code sample.

However, since there is this sample CCS code on the UCC5870QEVM-045 product page, I was wondering how to properly adapt and run this initialization code using SIMULINK custom C block.


How can I do this properly?
Plus, I didn't dig deep into the code, it is a bit complex and I want the module to just do the work, but are there changes to be done?

Thank you for your help!

  • 0
    TI__Prodigy 711 points

    Hello Jaerm, 

    Thanks for reaching out!

    We are are familiar with SIMULINK, but not familiar with the custom C block. From the gate driver point of view, I believe you can use the materials sent as base to attempt to make your own implementation. 

    Best regards,

    Jose Rojo

  • 0 in reply to Jose Rojo
    Prodigy 30 points

    Hi Jose!

    Thank you for your kind answer. I tried multiple things, and got nothing to work for now.

    My biggest issue so far is that it seems like I can't seem to figure how to make the sample code provided by TI work for me, even in CCS.

    I got the evaluation module ready, plugged the power source accordingly, attached the LaunchPad to the right pins, managed to make CCS build the project for RAM execution (Flash doesn't seem to work for some reason), and upload it to the LaunchPad, but the output is a static -7.7V for each of the six gate drivers.
    No PWM, none of the four LEDs on to signal an issue, nothing.

    I wanted to try sniffing the output of SPIA using an ESP32 running MicroPython, but sadly it isn't capable of that (it works only as master).

    Apart from that, I figured my best option wasn't the SIMULINK custom C block, but the Custom Code tab (Model configuration > Code Generation > Custom Code) where I can specify headers, source files, and "Initialize code" to run during initialization before the model starts. For now, I tried using that but the build fails. I didn't look further into that issue, since I can't even make the code work directly from CCS.

    Is it possible to have some help on the CCS part of that? I didn't change anything in the sample code, and others have managed to use that as is... What am I doing wrong? How am I supposed to make it work?

    EDIT: Nevermind, I managed to get it to work, it was a GND issue.
    I have yet to figure out how to run this properly through SIMULINK without encountering build issues.
    EDIT 2: It was good while it lasted... I have the D10 LED on, and most of the time the D12 LED on as well. I am investigating to debug this, but I don't see why.

    Thank you for your help.

  • 0 in reply to Jaerm
    TI__Prodigy 711 points

    Hello Jaerm,

    Could you clarify if you are able to run our sample code in CCS?

    D10 and D12 are used to indicate the status of nFLT1_HS and nFLT1_LS, respectively. Assuming that the CCS is functioning properly, could you read the status registers to further assess exactly which fault mechanisms are being triggered.

    Best regards,

    Jose Rojo

  • +1 in reply to Jose Rojo
    Prodigy 30 points

    Hi, sorry for the delay.

    Yes, I was able to run your sample code successfully a few times before encountering issues.

    However, I just bought a new one, because too many things were wrong, and it wasn't worth it anymore to debug it further, probably causing more problems along the way (more details about that at the end of this message).

    Still, here are the notes I took before it got worse, in case it might help in the future:

    --- Initial notes ---

    initFault, priReadyFault and secReadyFault are all equal to 0, no issue.

    statusFault = 0x0012, non-zero: there are issues described below, according to the driver's documentation and the value displayed on CCS.

    I identified the drivers faulting: it's the drivers 1 and 4 in the code (index from 0 to 5).

    ===== STATUS REGISTERS =====

    # status1

    Normal: 0x0080 = 0b0000.0000.1000.0000 <= this is the value non-faulty drivers have (drivers 0, 2, 3, and 5)

    Faulty: 0x0080 = 0b0000.0000.1000.0000 <= this is the value faulty drivers have (drivers 1 and 4)

    Faulty bits that are different, and their meaning: None here.

    # status2

    Normal: 0x4000 = 0b0100.0000.0000.0000

    Faulty: 0x4022 = 0b0100.0000.0010.0010

    Faulty bits that are different, and their meaning:

    • b5=CLK_MON_PRI_FAULT: A primary side Clock monitor fault is triggered because the received clock from the secondary side is mismatched from the primary clock (masked fault in the code, shouldn't cause an issue)
    • b1=OR_NFLT1_PRI: Indicates the logic OR of all primary side faults reporting to pin nFLT1 (fault NOT masked)

    # status3

    Normal: 0x0800 = 0b0000.1000.0000.0000

    Faulty: 0x3080 = 0b0011.0000.1000.0000

    Faulty bits that are different, and their meaning:

    • b13=INT_REG_SEC_FAULT: Internal regulator fault (fault NOT masked)
    • b12=INT_COMM_SEC_FAULT: A secondary side internal regulator fault is triggered because an internal rail on the secondary side (including VREG2) experiences an OV or UV event (fault NOT masked)
    • b11=MCLP_STATE: The 0 indicates that the Active Miller clamp is not active. VOUTH<VCLPTH (masked)
    • b7=UVLO2_FAULT: A UVLO2_FAULT fault is triggered because VVCC2 < VUVLO2TH. CFG4[UV2_DIS] must be '0' to enable VCC2 UV faults (fault NOT masked)

    # status4

    Normal: 0x0001 = 0b0000.0000.0000.0001

    Faulty: 0x0481 = 0b0000.0100.1000.0001

    Faulty bits that are different, and their meaning:

    • b10=OR_NFLT1_SEC: Indicates the logic OR of all secondary side faults reporting to pin nFLT1 (fault NOT masked)
    • b7=CLK_MON_SEC_FAULT: A secondary side clock monitor fault is triggered because the received clock from the primary side is mismatched from the secondary clock (masked fault)

    # status5

    Normal: 0x0000 = 0b0000.0000.0000.0000

    Faulty: 0x0000 = 0b0000.0000.0000.0000

    Faulty bits that are different, and their meaning: None here.

    --- End ---

    After trying to check the 15V voltage at the caps C17_x and C18_x, the LEDs D11 also went on and always went on along with D10 and D12 during further quick tests. Plus, the 15V voltage at driver 1 went from 15V before D11 was on to 300mV once D11.

    Further debugging showed that I might have shorted things around the caps tested and fried something.

    Moreover, the initial error might have been caused by a short when moving oscilloscope probes from driver 5 to driver 0, as their output diodes were fried (it's a shame I didn't test that first… It would have been less costly if that was all there was).

    I'll try to not repeat the same errors with the new module, and I'll make sure to add tape around pins when in use, to avoid shorts and mistakes. I hope it'll do, else I might not be able to continue working on that PoC.

    Anyway, thank you very much for your help.

  • 0 in reply to Jaerm
    TI__Prodigy 711 points

    Hello Jaerm,

    Sorry for the issues that you are facing, hope it goes better the second time around. I would also like to point out that we have a newer version of the driver available for evaluation, UCC588x-Q1. It is similar to the UCC5870-Q1 with improved performance and reliability.

    Please visit this FAQ for more information.

    Best regards,

    Jose Rojo

  • 0 in reply to Jose Rojo
    Prodigy 30 points

    Hello Jose,

    Thanks for the heads-up on UCC5880! I did see it, but there isn't a readily available EVM for 6 gate control and making it myself would have required more time and efforts than just bothering with SPI commands on the UCC5870.
    Plus, the UCC5870QEVM-045 was made for the F28379D that I am using, which is extra nice.

    If you have any more tips to avoid making terrible mistakes again, or if you are aware of an EVM doing what I want (six PWM 0V/3V to 0V/15V for gate driving), let me know, it might be useful sooner or later for my PoC.

    Best regards,
    Jearm.

  • 0 in reply to Jaerm
    TI__Prodigy 711 points

    Hello Jaerm, 

    We do not have an EVM of this manner available for UCC5881-Q1. 

    Couple of pointers is to make sure to read the ratings for each connection point. Following the user guide for setup is recommended as well. 

    Note: This EVM is primarily designed for software evaluation and is not practical in terms of driving FETs/power modules.