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.

F28M36x Technical Reference Manual Implies in section 4.1 that interrupts can be generated by ports M,N,P,Q,R,S but this appears to be false.

Other Parts Discussed in Thread: CONTROLSUITE

In section 4.1.1 of the concerto MCU user manual we can read that in relation to the first 9 ports (A-J) ...

Programmable control for GPIO interrupts

– Interrupt generation masking
– Edge-triggered on rising, falling, or both
– Level-sensitive on High or Low values

A paragraph below this we can read:

In addition to the above nine GPIO blocks, an additional eight GPIO blocks, each corresponding to an
individual GPIO port (Port K, Port L, Port M, Port N, Port P, Port Q, Port R, Port S) are available on this
device. These ports are accessible only by AHB bus and not accessible through the APB bus.
These new ports add an additional 64 GPIOs, bringing the total of available GPIOs on this device to 136,
depending on the configuration. The rest of the features on these 64 GPIOs are the same as above listed
for PortA to PortJ GPIOs.

...but the features on these 9 ports do not appear to include interrupt ability as interrupt registers only service up to interrupt number 91. So the features are not "the same"

-bradiko

  • Brad,

    We have interrupts beyond 91 but due to error in document it's not listed there. New document with fix should be available by end of next week.

    Regards,

    Vivek Singh
  • When the F28M36x is connected and debugged using Code composer studio 6.2, the register view shows the interrupt registers available. This view explicitly shows interrupt numbers for relevant registers (e.g. NVIC_PEND2 has interrupt bits for IRQ 64-95). As these registers are 32-bits wide, these numbers go from 0 to 95 across 3 numbered registers (NIVIC_PEND0, NVIC_PEND1, NVIC_PEND2). The interrupt number of port P which I am interested in is actually 116. So although the hw_ints.h I am using in the project from $TI Release: F28M36x Driver Library vAlpha1 has the number of interrupts defined within as:

    "#define NUM_INTERRUPTS 150"

    There is no way to use these in the hardware that I see. How will you add registers to the NVIC (e.g. NVIC_PEND3) to service the higher interrupts? Am I missing something you know? From here, it doesn't seem possible. the TRM and library files should be updated to make that clear (if true). If not true, I will be pleasantly surprised.

    -Bradford
  • Hi,

    These additional registers are available in hardware but not defined and documented. We are going to fix the documentation as well as SW issue in next release.

    Regards,

    Vivek Singh
  • Do you have any ballpark time-frame for this update? Any guess could help me to plan my project response (hardware change vs. software update). Would it be weeks, months or more than 3 months?
  • We are planning new controlSUITE release by mid Dec and that should include the fix.
  • Dec 20, 2016: TI Released a new version of F28M36x Device Support v209, but when I include this updated ControlSuite library, the required NVIC registers to allow IRQ on higher ports mentioned above are still not listed. Has this issue been resolved? If so how can I generate the IRQs on these ports? If not, when will there be a fix? This is a critical issue for us.
  • The registers are still accessible in hardware, it's just the defines aren't in the driverlib headers. The registers like NVIC_EN2/3 and friends are defined, but the interrupt numbers aren't. Driverlib also doesn't support setting them though the convenience functions like GPIOPortIntRegister.

    You can just set the bits in the right register manually, basically doing GPIOPortIntRegister manually. For example, to set an interrupt on PORTP. This is vector number 132, but interrupt number (i.e. the bit in the reg) 116. This means it goes in NVIC_EN3, which deals with interrupt numbers 96 to 127.

    IntRegister(INT_GPIOP, handler); // #define INT_GPIOP 132 from hw_ints.h
    
    HWREG(NVIC_EN3) = 1 << (116 - 96); // TRM 26.5.4 for the first interrupt in register (96), Table 25-17 for the interrupt number (116)

    It's not very convenient but it works. Technically it's faster too, since you don't need driverlib to translate into the right register values. It did take me quite a long time to realise what was going on, however, since naively using the driverlib functions gets you a vector in the table and no errors of any kind, but also never sets the NVIC_ENx bit.

    Do users of these parts actually use driverlib in production, in which case anyone wanting interrupts on the top 6 ports would have had to do it themselves since part release, or is it intended as more of a demo? Or is it just uncommon to has interrupts on the top 6 ports?

  • Thank you for this, John. I will get going with this workaround. Yes we will use interrupts on higher ports in planned designs. I will also consider adding the appropriate switches in the driverlib but your solution seems better.
  • I decided against patched my copy of driverlib, because then I need to keep all the changes to it in mind and port them to new releases in future. But if there's much more missing, I might consider it! Probably easiest is to check in each version to a VCS repo, then it's easy to see what has changed from release to release, and you can maintain your own changes in a separate branch if needed.

    Remember, there's nothing in driverlib that you can't do yourself, it's only 20-something .c files.
  • Thank you,

    I can confirm this was fixed in the version of control suite 2v10 (and retroactively fixed in 2v09), visualising the NVIC registers 3 and above in CCS was still not possible for me. But am working on that. The interrupts are working.

  • Hi Bradford,

    Thank you for the confirmation.

    Regards,

    Vivek Singh