ConfigTools Peripheral Initialization Order

[bhenning]

Is it possible to control the order in which peripherals are initialized when using ConfigTools?  I've run across a problem where I'm getting hard faults because GPIO is being initialized ahead of the RTC, and my GPIO interrupt code reads the RTC for debounce timing as well as measuring the length of a button press.  If I manually edit the BOARD_InitPeripherals method to put the call to RTC_init() ahead of the GPIOn_init() calls, everything is happy.  However, I don't see a way to control that from within the ConfigTools peripherals tab, and generated code seems to want to be in the order in which I originally added the peripherals.

This is only a problem just now because I recently moved from having user code set up the ports, to relying on the ConfigTools pin configuration tool.  Previously the interrupts weren't being enabled until after ALL of the ConfigTools generated initialization code had run.  I'd rather stick with having the ConfigTools be the authority on these settings, rather than overriding them in code.

I'm working with the FRDM-KL27Z development board, using MCUXpresso 11.2.0.

[gusarambula]

Hello Brian Henning,

There is not an option on the Config Tools that allows to switch the order in which the init calls appear on the generated code.

However, let me see if I can somehow reproduce this behavior as the order should not affect the behavior as, as you mentioned, interrupts would generally start after the initialization is done.

Regards,

Gustavo

[bhenning]

Hello Gustavo,

Thanks for getting involved.  I have my input pins configured to generate interrupts on either edge.  Some pins are driven LOW at reset and some are driven HIGH, and I think that's an important piece of the puzzle.  My hypothesis is that ISF is getting set because of the initial driven value of the pin when the port is configured, so that when the GPIO interrupt is turned on by the generated GPIO init code, it fires immediately (before other peripherals have been initialized).

Please let me know if you need any additional information from me in order to troubleshoot.

Thanks,

-Brian

[Lukas_Heczko]

Hi Brian, 

As Gustavo mentioned, feature to control order of initialization generated by Peripherals is not currently supported, however, to workaround your problem with GPIO interrupt invocation before the initialization is completed, you may also consider to set the GPIO interrupt request to "Not initialized" in the GPIO component:

This will prevent generation of "EnableIRQ()" call in the component init function, keeping the interrupt request disabled. You may enable the interrupt using "EnableIRQ()" after the component initialization finishes in your application code.

Regards,

Lukas

[bhenning · Accepted solution]

Hello Lukas,

Thank you for the suggestion.  I chose a different work-around, and created a separate Functional Group in the Peripherals Config Tools, and moved the RTC initialization into it.  Although only one Functional Group can be active at a time in the Peripherals section, I can call my separate Functional Group method from main() ahead of the BOARD_InitPeripherals default group, thereby ensuring the RTC is initialized first.

It seems like this problem wouldn't exist if the Peripherals Functional Groups worked more like the Pins Functional Groups -- multiple Groups can be active at once, and they're called in the order they're specified (and that order can be modified within the Config Tools UI).  I strongly suggest this as an enhancement to an otherwise quite agreeable tool.

Thanks.