TMS320F280049C: Loop-back tests for GPIOs and analog peripherals

Emily Birch

Part Number: TMS320F280049C

Hi, this set of questions is a result of going through the functional safety documentation for the TMS320F280049C uC. One of the many options is to validate the functionality of peripherals through some sort of loop back. In particular, for the purposes of this post I have a few lines of enquiry as to whether it is possible to perform loopback tests without the need for external hardware connections.

GPIO Loopback

Initially, I thought that it may be possible to have internal loop backs to test the operation of the GPIO input and outputs. Taking at the TMS320F28004x Technical Reference Manual (September 2020), it would look as though the GPIO can ONLY operate in either the input or output mode (image clip from TRF below)

However, I had a play at trying to see if it was possible to simultaneously read/write of the GPIO by using the XBAR. My question is whether this is an acceptable method performing GPIO loopback testing, in the view of functional safety? I tested this with the code snippet below on device, and it appears to work successfully. The flags to indicate whether the set/clear tests succeeded are all set at the end of the program when running under debug. It appears that it can read the XBAR output using input GPIOs, and can read the output GPIOs using the XBAR input. Note that I was using C2000 v3.04.00, CCS 10.3, and CGT 22.6.0.

Furthermore, given that not all GPIOs can be muxed to the XBAR, would it be valid to only test application critical GPIOs using this method from the perspective of functional safety? I.e. if there is a heart-beat LED blinky, that can be ignored as it does not affect functionality in any way.

#include <gpio.h>
#include <xbar.h>
#include <pin_map.h>

/**
 * main.c
 */
int main(void)
{
    // TEST GPIO INPUT: OUTPUTXBAR1 -> GPIO2 (via INPUTXBAR1)
    GPIO_setMasterCore(2, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_2_OUTPUTXBAR1);
    GPIO_setDirectionMode(2, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(2, GPIO_PIN_TYPE_STD);

    XBAR_setOutputMuxConfig(XBAR_OUTPUT1, XBAR_OUT_MUX01_INPUTXBAR1);
    XBAR_enableOutputMux(XBAR_OUTPUT1, XBAR_MUX01);

    XBAR_setInputPin(XBAR_INPUT1, 0xFFFE);
    bool inputIsSetTest = false;
    if (GPIO_readPin(2) != 0U) {
        inputIsSetTest = true;
    }

    XBAR_setInputPin(XBAR_INPUT1, 0xFFFF);
    bool inputIsClearTest = false;
    if (GPIO_readPin(2) == 0U) {
        inputIsClearTest = true;
    }

    // TEST GPIO OUTPUT: GPIO -> INPUTXBAR1
    GPIO_setMasterCore(2, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_2_GPIO2);
    GPIO_setDirectionMode(2, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(2, GPIO_PIN_TYPE_STD);
    GPIO_writePin(2, 0);
    XBAR_setInputPin(XBAR_INPUT1, 2);

    GPIO_writePin(2, 1);
    XBAR_clearInputFlag(XBAR_INPUT_FLG_INPUT1);
    // NO XBAR FILTERING, to allow the XBAR flag to get set in the few clock cycles
    // between the flag clear and get
    bool outputIsSetTest = false;
    if (XBAR_getInputFlagStatus(XBAR_INPUT_FLG_INPUT1) != 0U) {
        outputIsSetTest = true;
    }

    GPIO_writePin(2, 0);
    XBAR_clearInputFlag(XBAR_INPUT_FLG_INPUT1);
    // NO XBAR FILTERING, to allow the XBAR flag to get set in the few clock cycles
    // between the flag clear and get (in this case, we expect it not to get set)
    bool outputIsClearTest = false;
    if (XBAR_getInputFlagStatus(XBAR_INPUT_FLG_INPUT1) == 0U) {
        outputIsClearTest = true;
    }

	return 0;
}

Analog Loopback

My next questions are on analog loopbacks. I see that there is a previous post about DAC-ADC loopbacks here:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1065020/tms320f280049-dac-to-adc-loopback-check-xbar-loopback/3941144?tisearch=e2e-sitesearch&keymatch=GPIO%252520loopback#3941144

It appears that the only way to do internal ADC loopback tests is if the DAC pins also happen to be muxed on the same pin. Unfortunately for the TMS320F280049C in our application, this appears not to be useful. Again from the technical reference manual, it appears that only the ADC pins A0 and A1 (shown below) can mux to the DAC out. Is this a correct interpretation?

Given this, I also want to clarify whether this is true of performing loop back tests of the PGA peripherals. From the reference manual, it does not appear to be possible to loop back a DAC output into a PGA input pin internally. Can I also confirm whether this interpretation is correct?

Thanks!

Emily

over 1 year ago

0 Whitney Dewey over 1 year ago

TI__Guru 53745 points

Your GPIO test scheme looks good. In the first part of the test, the pin isn't truly configured as a GPIO input since GPyDIR doesn't have an effect when a pin is set to a non-GPIO mux selection, but you are still able to test of the GPyDAT pin status read while it is being driven by something other than the GPyDAT output latch. For the output test, since a read of GPyDAT reflects pin status and not the GPyDAT output latch, you probably could just read GPyDAT instead of (or in addition to?) using the XBAR flag.

For ADC-DAC loopback, you're right--internal loopback on this device depends on shared pins. It looks like you can do DACA-A0, DACA-B15, DACA-C15 and DACB-A1, so it won't give you much pin/channel coverage, but it does at least allow you to test each ADC instance (A, B, and C).

I agree with your conclusion about PGA.

Whitney

0 Emily Birch over 1 year ago in reply to Whitney Dewey

Prodigy 110 points

1. For the GPIOs, would it be correct to say that the input and output paths are independent, and the direction of a GPIO is effectively only controlling whether a write to DAT/SET/CLR will modify the output latch? In which case, I would agree that the GPIO output test would not require the use of the XBAR, as the functionality under test (GPIO output) is being tested by an independent function (GPIO input).

If it is the case that the output and input are considered independent, would it then be the case that, from a functional safety standpoint, the process of writing the GPIO output latch and reading that value back is a sufficient loopback test for both the output and input path? This would then mean that the XBAR does not need to be used, which then means more GPIO pins can be tested (as not all GPIO pins have output XBAR mux options).

2. Agreed, I did not need to configure the GPIO direction for the XBAR input!

3. As you say, at least for the DAC-ADC loopback we can test each ADC instance, but sadly not every channel of each instance.

Given your feedback, I have updated my example code snippet for future reference.

#include <gpio.h>
#include <xbar.h>
#include <pin_map.h>

/**
 * TMS320F280049C GPIO Loopback Self-Test
 */
int main(void)
{
    // TEST GPIO INPUT: OUTPUTXBAR1 -> GPIO2 (via INPUTXBAR1)
    GPIO_setMasterCore(2, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_2_OUTPUTXBAR1);
    GPIO_setPadConfig(2, GPIO_PIN_TYPE_STD);
    XBAR_setOutputMuxConfig(XBAR_OUTPUT1, XBAR_OUT_MUX01_INPUTXBAR1);
    XBAR_enableOutputMux(XBAR_OUTPUT1, XBAR_MUX01);

    XBAR_setInputPin(XBAR_INPUT1, 0xFFFE);
    bool inputIsSetTest = false;
    if (GPIO_readPin(2) != 0U) {
        inputIsSetTest = true;
    }

    XBAR_setInputPin(XBAR_INPUT1, 0xFFFF);
    bool inputIsClearTest = false;
    if (GPIO_readPin(2) == 0U) {
        inputIsClearTest = true;
    }

    // TEST GPIO OUTPUT: GPIO OUT -> GPIO IN
    GPIO_setMasterCore(2, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_2_GPIO2);
    GPIO_writePin(2, 0);
    GPIO_setDirectionMode(2, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(2, GPIO_PIN_TYPE_STD);

    GPIO_writePin(2, 1);
    bool outputIsSetTest = false;
    if (GPIO_readPin(2) != 0U) {
        outputIsSetTest = true;
    }

    GPIO_writePin(2, 0);
    bool outputIsClearTest = false;
    if (GPIO_readPin(2) == 0U) {
        outputIsClearTest = true;
    }

	return 0;
}

0 Whitney Dewey over 1 year ago in reply to Emily Birch

TI__Guru 53745 points

Hi Emily,

Can I ask what kind of safety you're doing? Is this for an ASIL B system?

One thing to note is that without using an external connection, you have a potential common cause failure at the pin--things may look as expected internally in the register, but there could be a disconnect with the actual external status. On critical IOs, do you intend to implement hardware redundancy?

Whitney

0 Emily Birch over 1 year ago in reply to Whitney Dewey

Prodigy 110 points

Hi Whitney,

Yes we are working towards ASIL B for our system. For GPIOs that would be considered critical to function, there is not redundancy. It sounds like internal loopback testing is not sufficient coverage, and an external loopback is required.

Thanks, Emily

EDIT:

I just want to clarify that I am looking specifically Section 6.7.13 Software Test of Function Using I/O Loopback from the functional safety manual (SPRUID8D – SEPTEMBER 2020 – REVISED JANUARY 2022), which has the ID GPIO 4

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280049C: Loop-back tests for GPIOs and analog peripherals