TMS320F28335: SFO function causing floating point exception due to computing 0/0

I should mention that I am using V5B of the SFO library.

I just tried going back to just V5, and did not have this issue -- I could repeatedly call SFO_MepDis_V5() at will for any channel.

I also tried running the TI SFO example as-is with the V5B library, except that I called SFO_MepDis_V5() multiple times (copied/pasted from the example), and I saw the same behavior. In other words, even the TI example project fails with V5B of the library if you call SFO_MepDis_V5() more than once for any channel.

So basically as far as I can tell SFO_MepDis_V5() in V5B of the library does not function correctly. Not only that, it gives a floating point exception, which is really quite nasty.

Hi Joel, 

Which version of C2000Ware are you currently using? And to confirm, is the TI example you are referring to the hrpwm_sfo_v5 example or a different sfo example? I will try to run the example on hardware as well to see if it creates the same issue.

Regards,

Allison

Hi Allison

I am using C2000Ware 5.0.0.0, and ti-cgt-c2000_22.6.0.LTS.

The example I ran was hrpwm_sfo_v5. I simply modified the code to run the following loop twice instead of simply once.

    for(i=1;i<PWM_CH;i++)
    {
        //
        // Enable HRPWM logic for channel prior to calibration
        //
        (*ePWM[i]).HRCNFG.bit.EDGMODE = 1;
        
        while ( SFO_MepDis_V5(i) == SFO_INCOMPLETE );
        {
            //
            // returns "0" when cal. incomplete for channel
            //
        }
    }

After the first time, the MEP_ScaleFactor[ ] array values were each 50 or so counts. After the second time, every entry was 32767. With my actual application (which does not use C2000Ware directly, but uses code derived from it), I have floating point exceptions enabled, and I end up getting 32768 for every MEP_ScaleFactor[ ] entry, along with exceptions along the way.

Hi Joel, 

I repeated the loop in the TI example and was able to see the ~32767 MEP_ScaleFactor[] array and the jump to MEP error as you described. Can I ask if there a reason why you are needing to call the MEP disable loop more than once in a row? Is the 0/0 fp error seen in your program then different from what we are finding in the example? If you can also provide more on the application of the device and need for HRPWM as well- have you tried SFO_MepEn to see if it yields the same errors in your program? I've also reached out to an SFO library expert to gather more input on if there is something specific to the SFO library that may be causing what you're seeing since you did not see the issue in your program with the other version. 

Regards,

Allison

Hi Allison

Thank you for looking into this.

Our application is a very high temperature (175 deg C) servo controller, PWMing at 96 kHz, needing about 14 effective bits of D/A. With the high temperature, we are limited in CPU frequency to about 100 MHz. With the 96 kHz on top of that, our resolution is nowhere near 14 bit without the HRPWM.

My application actually does not call the MEP disable loop repeatedly; it calls it about once per second in the background, as suggested in the TI literature. My understanding from the literature is that if a PWM channel does not use HRPWM, the most efficient means of calibrating the MEP scale factor is to call the MEP Disable routine occasionally using that channel. This approach also keeps the supported HRPWM min and max duty cycles at their largest range . However, upon implementing this, I was seeing the 0 / 0 and the FP exception. So in order to help narrow things down and eliminate things such as interrupt handlers etc, I went to a very basic program that simply called things twice in my startup code. This proved that our application's interrupts, etc, had nothing to do with the issue.

I suspect that the behavior I see (0/0 with 32768 MEP scale factor) is the same root cause as the TI application's 32767 MEP scale factor. I'm not sure what the root cause is because I don't have access to the C source for the SFO library, but my guess is that, depending on what else is happening on the stack and other registers, subtly different "bad" things can happen.

Using the SFO_MepEn library may be an option, but it would not be our starting solution based on its documented limitations (slower, and larger reduction on the duty cycle range). Based on only the TI literature, the natural choice for our application would be SFO_MepDis, and not SFO_MepEn.

Another challenge I will have is that we have to certify this application to DO-178C DAL A for flight. This means all source code needs to be fully known and certified for safety. The SOF library presents a challenge here. Obviously code that can generate an FP exception is not certifiable. So at some point I may need to reach out to you (TI) for support as to how we can understand the code layout and intent so that it can be verified.

Thanks

Joel

Joel,

Thanks so much for the detailed response. Yes, you will want to you SFO_MepDis() for quicker optimization as opposed to SFO_MepEn(). As a side note: please be wary that the 175degC is also out of spec for this device. I do not currently have access to the library source, but am waiting to hear back about if it is able to be accessed. I understand that you will need to be familiar with the library source code, regardless, with the flight safety certification, and will get back to you about these early next week. I will continue look into the issue and try to verify that V5B library is part of the cause here and keep you updated on my findings.

Regards,

Allison

Hi Allison

We will actually be using the SM320F28335-HT in flight, which I believe supports a junction temperature of up to 150 or 210 deg C, depending on the packaging. For lab development, though, we are using the standard TMS320F28335.

Thanks

Joel

Hi Joel,

Good to hear you're planning on HT version, thanks for the clarification on that- just wanted to double check to be sure. I also did verify that another example in V5 version with a similar program and found that it worked as it should but threw the MEP error with V5B. Still waiting to hear back about the SFO library source access so I can get more visibility into the issue, but I will be sure to update you early next week on this as soon as I hear back. I appreciate your patience, Joel.

Regards,

Allison

Hi Joel,

Thanks again for your patience. The SFO library source access is proprietary to TI, so we are unfortunately unable to support the request to review it. In terms of resolving the immediate issue of your post, it is recommended you utilize the V5 library for your program. I realize that there are safety certification inquiries for the application as well; for this, you can also utilize the disassembly found within CCS. Please let me know if there is anything else I can help you with here.

Regards,

Allison

Hi Allison

I have a few follow-up questions/comments.

1. Will TI be adding an erratum for the fact that the SFO_MepDis() function in the V5B library does not work as advertised?

2. SPRUI07 says, "TI provides a C-callable library containing two SFO functions that utilize this hardware and determines the optimum MEP_ScaleFactor. As such, MEP Control and Diagnostics registers are reserved for TI use." Above, you say, "The SFO library source access is proprietary to TI, so we are unfortunately unable to support the request to review it." So TI does not provide details of the registers involved, and does not provide access to the source code that uses them. I think this means that the HRPWM cannot be used in a safety-critical application, because it will be pretty much impossible to prove that the called function(s) operate correctly (in fact, they don't in at least one version of the library). Can TI work with us off-line via a Non-Disclosure Agreement or something to that effect to provide us access to the necessary information? If not, TI's stance likely means we will be forced to choose a different solution.

Thanks

Joel

Hi Joel, 

Thank you for your questions and comments. In regards to your first question, these software-focused types of errors are not generally the type of content we include in the device errata. Instead, I am looking into where this type of SFO software-related information normally lives. In terms of your second point, this F2833x device is not pre-certified for any safety-critical application, so we unfortunately cannot guarantee that it will be able to support the requirements for safety certification processes. I will be sure to consult with other experts and determine if there is any other support we can still offer you, I appreciate your patience as we look into this. I also want to note that while F28335 remains a consistent active TI part, I would also highly encourage you to look into newer generation C2000 devices which support more peripherals, have enhanced features, have existing safety certifications and support, and are found at lower costs (for example, F2807x or F2837xS). 

Regards,

Allison

Hi Allison

I was not aware there was a high temperature F2837xS device available. Please point me to it.

Thanks

Joel

Hi Joel,

My apologies, I mistook the operating temperature range of my suggested devices for the flight application. You are correct that F28335-HT is the only available device to fit the 175degC+ temperature of your operating environment. I realize the issue with this and needing access to the source for safety purposes. There has been some consideration with regards to releasing under NDA but we are also now having some trouble accessing the source internally since this is a legacy device and the original source was developed years ago on a completely different infrastructure than what is used today. I am actively looking into this and will update you again tomorrow or as soon as I hear back from another who is currently on travel.

Regards,

Allison 

Hi Joel,

Thanks again for your patience. To update you, we do not have access to the older V5 versions of the SFO library. We do have the latest SFO library V8 source; however, I do not know the V8 library to be compatible with older generation devices. I will check on this to be 100% sure we have explored all options and will get back to you early next week when I can confirm. Please let me know if you have further questions or comments in the meantime.

Regards,

Allison

Hi Joel,

Thanks so much for waiting. We have secured the SFO V5 source and are under discussion internally on how to share this with you. I will update you as I hear back, but please let me know if there are updates on your end in regards to this as well. 

Best regards,

Allison

Hi Joel,

Just following up to confirm if you are still wanting access to the SFO library V5 source since this thread has gone quiet for some time. We can go through the process of giving you access through secure software, but I wanted to verify that this is still what you are looking for before I get much further into the process of packaging it. I also did reach out to an FAE contact to see if he knew of any push to gain source access but I haven't heard back, so thought I'd post back here. Please let me know if this is still the path you wish to take or if there's anything else I can do to help.

Thanks and regards,

Allison 

Hi Allison

Yes; we are still in need of access to the SFO library V5 source. Sorry for being quiet, but I don't have much to contribute to the discussion at this point as I am simply in a waiting mode.

Thanks

Joel

Thanks for getting back to me, Joel. Sounds good! I will continue with the process. We can continue this via email if you prefer as well.

Regards,

Allison

Hi Joel,

Just reached out via email. Let me know if there is an issue in receiving it.

Regards,

Allison