• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 467 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.

Incorrect ASSERT in TivaWare 1.0 HibernateClockConfig function

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: TM4C1233H6PM

I was calling the following in TivaWare 1.0, set for debugging so that uses the driverlib library compiled with assert checks enabled:

  MAP_HibernateClockConfig (HIBERNATE_OSC_HIGHDRIVE);

Which caused the following ASSERT to fail:

void
HibernateClockConfig(uint32_t ui32Config)
{
      uint32_t ui32HIBCtl;

      ASSERT((ui32Config & (HIBERNATE_OSC_HIGHDRIVE | HIBERNATE_OSC_LOWDRIVE |
                                                  HIBERNATE_OSC_DISABLE)) == 0);

The ASSERT looks wrong since it will fail when passed valid arguments (as in this case).

  • 0
    Guru 92251 points

    The assert should be:

    void
    HibernateClockConfig(uint32_t ui32Config)
    {
        uint32_t ui32HIBCtl;

        ASSERT((ui32Config & ~(HIBERNATE_OSC_HIGHDRIVE | HIBERNATE_OSC_LOWDRIVE |
                              HIBERNATE_OSC_DISABLE)) == 0);

    Also the following in hibernate.h set bits 17 and 18:

    #define HIBERNATE_OSC_LOWDRIVE  0x00040000
    #define HIBERNATE_OSC_HIGHDRIVE 0x00060000

    According to the TM4C1233H6PM datasheet in the Hibernation Control (HIBCTL) register bit 18 is reserved. OSCDRV is in bit 17 defined as:
    0 Low drive strength is enabled, 12 pF.
    1 High drive strength is enabled, 24 pF.
    i.e. driverlib is attempting to set the reserved bit 18 in the Hibernation Control register. Suggest that to avoid possible problems with future devices that driverlib shouldn't attempt to use reserved bits.

  • 0 in reply to Chester Gillon
    TI__Genius 9035 points

    That is a good catch on the ASSERT() it certainly should have the ~ operator in front or all valid configurations cause asserts.  The bit definition for HIBERNATE_OSC_HIGHDRIVE is just incorrect, the extra bit does not need to be set but I checked and setting it is harmless.  I will open an issue to get both of these fixed in our next release.  

    Thanks!