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.

TM4C129 class missing from ROM_GPIOPadConfigSet

TivaWare: 2.1.0.12573

Problem: In rom.h, 

ROM_GPIOPadConfigSet() for target class TM4C129

#if defined(TARGET_IS_TM4C123_RA1) || \
defined(TARGET_IS_TM4C123_RA3) || \
defined(TARGET_IS_TM4C123_RB1)
#define ROM_GPIOPadConfigSet \
((void (*)(uint32_t ui32Port, \
uint8_t ui8Pins, \
uint32_t ui32Strength, \
uint32_t ui32PadType))ROM_GPIOTABLE[5])
#endif
#if defined(TARGET_IS_TM4C123_RA1) || \
defined(TARGET_IS_TM4C123_RA3) || \
defined(TARGET_IS_TM4C123_RB1) || \
defined(TARGET_IS_TM4C129_RA0) || \
defined(TARGET_IS_TM4C129_RA1)
#define ROM_GPIOPadConfigGet \
((void (*)(uint32_t ui32Port, \
uint8_t ui8Pin, \
uint32_t *pui32Strength, \
uint32_t *pui32PadType))ROM_GPIOTABLE[6])
#endif

The TARGET_IS_TM4C129... checks are missing for the Set function. Is this an over-site or intentional? The function is documented in the ROM user guide (spmu_363)

Thanks

  • Hello Jeff

    Is it not an over-site. There is an issue with the manner the ROM function sets the drive strength for TM4C129 devices, because of which TM4C129 defines were removed for 2.1.0 release. If you have 2.0.1 release, then you would find it is there, but using the function from ROM would cause lower drive strength to be selected rather than the >10mA drive strengths

    Regards

    Amit

  • Thanks for the reply.

    Does this (or should this) appear in the Errata?

    Thanks,

    Jeff

  • Hello Jeff,

    It was a programming sequence issue and not a functionality issue. That is why it did not make it's way to the errata. But point noted and will try to see if it can be put in errata/documented.

    Regards

    Amit

  • Amit - I would argue that any issues in the ROM code would be a functionality issue. There may be an easy workaround but it should still be captured in the Errata. Just my two cents worth.

    Thanks,

    Jeff

  • Jeff McDevitt said:
    I would argue that any issues in the ROM code would be a functionality issue.

    Suspect that you're right - hard for the "giant" to admit/acknowledge mistake - this issue/others explains our group's "hesitation" to employ (relatively) new devices.  (from most vendors)

  • Hello,

    I concur with the sentiment above, although my primary objection is that incorporating StellarisWare/TivaWare into the device is a waste of transistors.  It is firmware, and most applications use only a small portion of it, at best.  Any intelligent linker will remove the "sections" that are not referenced to reduce the size of the executable.

    In addition, freezing this code into the die captures any bugs permanently as well as creating a management nightmare.  It then becomes "baggage" rather than an asset.  I firmly believe the firmware-based  StellarisWare/TivaWare concept is better than any of the competitors, but its degree of use/presence should be the users decision.  From my recollection, pretty each silicon release has at least one errata due to ROM functions that have not gotten reved to match the silicon changes.  If it was firmware, it would only be a short term problem...

    I vote to save those much-heralded 65nm transistors and put them to better use - more performance or functionality.  Or, much needed cost reduction!

    Regards,
    Dave

  • If possible/proper - this reporter concurs w/your concurrence. 

    During the LMI acquisition hopes were high for promised/hinted, "price down."  Review of competing M4 devices shows that any such price-down did not land - w/much hoped for impact - here...

    And - do (likely) credit UCLA for (above) poster's appropriation of, "/" (use/presence) and "heralded" - both past arriving repeatedly here - this reporter's (Cortex-based) pen...