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.

Limitations of MWare driverlib with respect to Concerto F28M36x devices (GPIO ports > J)

Other Parts Discussed in Thread: F28M36P63C2

I've run into a rather frustratingly simple problem while programming the M3 core on an F28M36P63C2 device using the V208 MWare driverlib.

I was trying to set up a pin interrupt on Port N, pin 5 using the following code:

GPIOPinTypeGPIOInput (GPIO_PORTN_BASE, GPIO_PIN_5);
GPIOIntTypeSet       (GPIO_PORTN_BASE, GPIO_PIN_5, GPIO_FALLING_EDGE);
GPIOPinIntEnable     (GPIO_PORTN_BASE, GPIO_PIN_5);

IntRegister (INT_GPION, _portn_isr); // can't use GPIOPortIntRegister() for PORT N
IntEnable   (INT_GPION);

I noticed that the driverlib GPIOPortIntRegister() function called GPIOGetIntNumber() on the port base address, but that GPIO_PORTN_BASE isn't listed in the switch statement in that function (it only goes as far as Port J). However, GPIOBaseValid() allows GPIO_PORTN_AHB_BASE and INT_PORTN is defined. GPIOGetIntNumber() does return -1 in the default case, but there is no check on that number before handing it to IntRegister().

I used IntRegister() and IntEnable() manually instead. However, what I didn't notice (and I should have, since I just saw evidence of port N being missing) was that IntEnable() also doesn't support interrupts that go into registers NVIC_EN3 and NVIC_EN4, and silently ignores attempts to register interrupts in these registers. However, IntRegister() worked fine and emplaced the ISR, and both functions did "ASSERT(ulInterrupt < NUM_INTERRUPTS)" and passed (INT_PORTN == 128). There was no sign of a problem at compile time and the only symptom was missing ISR calls, despite the handler being registered in the NVIC table. No ASSERTs were ever triggered to indicate invalid runtime arguments.

Manually setting NVIC_EN4 using HWREG fixed my issue, but I am now wondering what the limitations of using driverlib are: other than the GPIO ports greater than Port J, are there other peripherals or functions that I should be aware of limited functionality in driverlib for the F28M36 devices? Is it expected that I should amend the driverlib code to support these ports, or is there a reason these ports aren't available in driverlib that I'd run into if I patched my copy?

NVIC_EN3 and  NVIC_EN4 only appeared in hw_nvic.h in MWare v208, so perhaps this functionality is on the way? However, it appears to be totally missing from TIRTOS's (tirtos_c2000_2_16_01_14) version of MWare, which is "v202a".

  • Hi John,

    I'll file bug reports to get those interrupts supported in IntEnable(), IntDisable(), IntPendSet(), IntPendClear(), and GPIOGetIntNumber(). I think those are the only ones with issues, but let me know if you stumble across more. As you pointed out, we recently fixed the header file, but failed to comb through the related driver code to find similar issues. Thanks for reporting this.

    Edit: IntPrioritySet() and IntPriorityGet() require updates as well.

    Whitney

  • Hi Whitney,

    Thanks for that fast response!

    It's good to know that it's just some missing cases, and I haven't missed a huge warning sign that I'm doing everything all wrong!

    I did also notice earlier that the "EPI Host-Bus [8/16] Timing Extension" registers are also missing from epi.h/.c. I found an example somewhere on E2E (not sure what target platform) that used a function called EPIConfigHB8TimingSet and macros like EPI_HB8_CAP_WIDTH_2, but this didn't work for me, as they were all missing. I just moved on, as I don't need to set those registers away from the defaults, and I'm happy to just access registers directly if needed, but I did think it odd. I'm not sure how far driverlib is expected to go in supporting every single register and field?

    In the case that these things are useful to mention, is the best way to note this kind of thing in future just to start a new thread on E2E?

    Thanks,

    John

  • Hi John,

    Yes, I would suggest to start a new E2E post.

    On EPI query, this IP was enhanced on other platform later hence F28M36x device may not have all the macros defined.

    Regards,
    Vivek Singh
  • Hi John, yes, this was known before: see post e2e.ti.com/.../552983 . But although TI released new device support version recently and indicated it would have been fixed in release v209. It still hasn't been fixed -- unfortunately for us both!
  • Yes, this was known before: see post e2e.ti.com/.../552983 . But although TI released new device support version recently and indicated that this would have been fixed in release v209. It still hasn't been fixed -- unfortunately for us both!