• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 2397 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.

TMS320F280039C: GPIO H AIO configuration and pin mapping

Stefan Schiffer1
Prodigy 160 points

Part Number: TMS320F280039C
Other Parts Discussed in Thread: LAUNCHXL-F280039C, , SYSCONFIG, C2000WARE

Hi,

I am using a TMS320F280039C on the LAUNCHXL-F280039C and have some trouble with the APIO H analog pins. I want to configure ADCINA1 as input for one comparator subsystem. ADCINA1 is connected to Pin A1/B7/DACB_OUT of the controller.

I wanted to write all the code from scratch, to learn how the MCU works. I read all the necessary section from the technical reference maual SPRUIW9A and device datasheet SPRSP61A.

According to the GPHAMSEL register definition on page 1136 of SPRUIW9A i need to set the corresponding register for my ADCINA1 input. As described on page 1136, the default values of GPHAMSEl are all bit set to 0x1, which means all analog functions are enabled.

Table 15-3 on page 1759 of SPRUIW9A shows that A1/B7/DACB_OUT is connected to AIO232.

The AIO pins are described on page 1054 of SPRUIW9A. There is no mapping, but from my understanding AIO232 is just a synonym to GPIO232.

So if I only want to activate A1/B7/DACB_OUT as analog input, I don't have to configure anything according to the manaul, because everything is already configured for my purposes. But the bit definitions of the GPHAMSEL must be wrong. The comparator only works if the GPHAMSEL is cleared. The test designs from TI I have seen so far do this with the bit-field function InitGpio().

First I tried to clear all bits in GPHAMSEL register. My comparator worked as expected. After the fundamental function test I wanted to clean up my code. By doing this I just wanted to enable A1/B7/DACB_OUT as analog input by clearing just bit 8 (GPIO232) in the GPHAMSEL register. But the comparator did not work in this configuration. By cheking all bits separately in debug mode, i found that GPIO242 instead GPIO232 must be cleard for A1/B7/DACB_OUT as analog input. This means that there are at least two wrong pin mappings in Table 15-2.

I am not familiar with MCU design. In the past i worked with FPGAs, so maybe I'm missing a critical part for correct initialization. I would be very grateful for any help.

Best regards,

Stefan

  • 0
    TI__Mastermind 19795 points

    Hi Stefan,

    Thanks for your question and walk-through on the issue. To answer each part:

    Stefan Schiffer1 said:
    the default values of GPHAMSEl are all bit set to 0x1, which means all analog functions are enabled.

    This is true of all analog-connected pins except AGPIO pins. AGPIO pins are fully disconnected (no analog -or- digital functionality) by default. This doesn't affect the items you have mentioned though, so I will continue with the rest.

    Stefan Schiffer1 said:
    By cheking all bits separately in debug mode, i found that GPIO242 instead GPIO232 must be cleard for A1/B7/DACB_OUT as analog input.

    This seems a bit odd as it is an exactly 10 offset from the expected. Can you do a quick test by trying another AIO (preferably one close, like GPIO233 OR GPIO231) and seeing if the bit that controls it is also 10 off? If so, I believe there may be an offset issue in the code used to access these registers. Likely the issue is setting 1 bit per GPIO instead of 2 bits per GPIO (the MUX registers are all 2 bits per GPIO, the AMSEL register is 1 bit per GPIO)

    You can sanity check this by trying the same in C2000Ware's Sysconfig.

    A few other things to sanity check:

    1. Does the code clear the GPHMUX register fields first for the GPIO (to avoid glitches)? (this is 2 bits per GPIO, so be careful here)

    2. Does the code write the GPHGMUX register value after #1 above? (this is 2 bits per GPIO, so be careful here)

    3. Does the code write the value into the MUX register after #1 and #2 above? (this is 2 bits per GPIO, so be careful here)

    4. Does the code set the "GPHAMSEL" register bits for this register? NOTE: THIS IS DIFFERENT THAN THE OTHERS, IT IS 1 BIT PER GPIO, BE CAREFUL HERE

    Regards,

    Vince

  • 0 in reply to Vince
    Prodigy 160 points

    Hi Vince,

    thank you very much for your answer.

    I tried several things today and finally found a bug in my code a few minutes ago. Shame on me :/

    The GPHGMUX and GPHMUX registers were configured correctly as they were on default. I had tried different analogue input pins as cmpss sources and the same problem always came up. Every time the GPHAMSEL.bit.GPIO242 was set high, the cmpss did not work correctly. When I cleared the bit, everything worked fine at first glance.

    I found the reason for this problem in the datasheet of the device (SPRSP61A): AIO232 and VDAC are on the same pin. I didn't want to use the external DAC reference source, but during programming I didn't know if we will use an external voltage reference source for all analogue components. So I wrote both configurations but forgot to comment out one of them. The VDAC was configured as a DAC reference. After I changed the DAC source to the internal source, everything went fine and of course GPHAMSEL.bit.GPIO242 no longer affected the design.

    The VDAC/B3/AIO242 pin was floating all the time. So there was no way that the cmpss could operate correctly. I didn't notice this for a long time because I only worked with GND and 3V3 cmpss input levels.

    Thank you for your support.

    Best regards,

    Stefan