ConfigTools Peripheral Initialization Order

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

ConfigTools Peripheral Initialization Order

ソリューションへジャンプ
2,981件の閲覧回数
bhenning
Contributor III

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.

ラベル(1)
1 解決策
2,838件の閲覧回数
bhenning
Contributor III

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.

元の投稿で解決策を見る

0 件の賞賛
4 返答(返信)
2,838件の閲覧回数
gusarambula
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
2,838件の閲覧回数
bhenning
Contributor III

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

0 件の賞賛
2,838件の閲覧回数
Lukas_Heczko
NXP Employee
NXP Employee

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:

pastedImage_3.png

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

2,839件の閲覧回数
bhenning
Contributor III

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.

0 件の賞賛