GPIO in PEx is so bizarre...

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIO in PEx is so bizarre...

Jump to solution
886 Views
dave408
Senior Contributor II

I have GPIO in Atollic with PEx working (bitbanged SPI), using the BitIO component.  However, in KDS+PEx, I don't have that component for some reason.  My non-PEx bitbang SPI code doesn't work, so I decided to use PEx in KDS.


I tried fsl_gpio, but there seems to be a bug where I cannot assign the port.  If I select PORTD, for example, it switches back to PORTA as soon as I click somewhere else.  And of course, since I want two (different) ports, I get an additional error saying that the two components are sharing a port.

So I decided to move on to try the GenericBitIO component in KDS+PEx.  Setup seemed clear enough until I saw this GUI:

pastedImage_0.png

I already set the Direction under the Component Name, so I don't understand why I would have to set something in a Direction tab.  In addition, I tried to figure out the significance of PTADD_PTADD0, but I can't find any part of that in the reference manual.  Also, the checkbox should really just be labeled "Output" or "Is output".

I was going to keep moving forward and just ignore this detail regarding direction, but I also can't figure out what the valid port names or bit names are that I should be using.  When PEx uses a droplist with the header and pin number (e.g. J2_12), it's so much easier to configure.  Droplists >> textboxes!

I had BitIO in Atollic+PEx working in 5 minutes.  So far, I've spent over four hours trying to get my IO code working in KDS.  I'm not sure why this is, but I'm going to keep plugging away at it.

0 Kudos
1 Solution
366 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Dave:

I posted a video about using fsl_gpio component in the next link: Video Link : 3195

Apart from the video I would like to clarify some points with you:

- As colleague Filip mentioned, in the fsl_gpio component the device selection (PORTA, PORTB, ...) is not relevant, since the component allows you to allocate any pins from any ports as inputs/outputs.

- You only need one fsl_gpio component, just add all of your required pins to the input and output configurations. In the video I use PORTC for the input button and PORTB for the LEDs, but I could have also added the green LED (which belongs to PORTE) without any extra component.

- I think the GenericBitIO is a custom Processor Expert component created by colleague Erich Styger, right? So we cannot help much with that one.

- If you do not feel comfortable with KSDK yet and would prefer to use the BitIO or BitIO_LDD component, just from the New Project Wizard uncheck the "Kinetis SDK" option. BitIO is part of the legacy Processor Expert components, which will not be available anymore for new Kinetis devices, but for K64 you can still use them. The next is a discussion about this: Re: How do I merge PEx components from PEx DriverSuite into KDS/SDK?

I hope this helps with your confusion.

Regards!

Jorge Gonzalez

View solution in original post

0 Kudos
17 Replies
366 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Dave,

1. I saw you said "fsl_gpio" , so please tell me do you use KSDK ?  In other words , when you create project ,have you selected here :

2. Please tell me the version of KDS and KSDK ,and  which chip do you use ?  Then i can quickly repeat your error and find solution.

BR

Alice

0 Kudos
366 Views
dave408
Senior Contributor II

Hi Alice, yes, I'm using KDS 2.0 + KSDK 1.1 + PEx, and have two problems:

  1. fsl_gpio doesn't take the port that I have assigned to the component -- it reverts to PORTA every time.
  2. I don't understand what to set in GenericBitIO.  I entered in port names but they ent up coming up as undefined.  The default is PTAD, which is accepted, but does that mean port A or port D?  For example, is Port B then assigned to PTBD or PTAB?  A droplist would make things a lot less ambiguous, and other components use them for ports, so I imagine it's possible with this component as well.  :smileyhappy:

I'm doing everything on a FRDM-K64F development board, so it's the MK64FN1M0VLL12.

Thanks!

0 Kudos
366 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Dave,

I have some doubts. Please see my screenshot :

pastedImage_0.png

this is my fsl_gpio component, we can select port in "Device" , and on my side , there is no GenericBitIO component , could you please screenshot yours , like this :

pastedImage_1.png

0 Kudos
366 Views
dave408
Senior Contributor II

Alice, here's a video of the bug in action.

0 Kudos
366 Views
vfilip
NXP Employee
NXP Employee

Hi,

the Device item in fsl_gpio component should not be visible and it is really confusing (switch to old inspector should resolve it). Please note that fsl_gpio can handle pins from multiple ports. It is recommended to have one gpio component in project. However you should be able to have more components in projects. If this is not allowed in 1.1 we can provide hot-fix if needed.

rgds

Vojtech Filip

0 Kudos
366 Views
dave408
Senior Contributor II

Alice, I can select the Port just fine.  But like I said earlier, when I click somewhere else and come back to the the Device selection, it changes back to PORTA.

Here is my screenshot:

pastedImage_0.png

0 Kudos
366 Views
vfilip
NXP Employee
NXP Employee

Hello,

the Device item should not be visible. It is problem in PEx for KSDK 1.1.0 (already fixed in PEx for KSDK 1.2.0). As workaround please ignore it or switch to old inspector view (details attached).

We are sorry for inconvenience.

rgds

Vojtech Filip

366 Views
dave408
Senior Contributor II

Hi Filip, back to my problems with fsl_gpio -- I am probably doing something really dumb, but I cannot get fsl_gpio to set any digital outputs.  Here is what my configuration looks like in PEx:

pastedImage_0.png

pastedImage_1.png

pastedImage_2.png

I thought that maybe I had to set the pin directions manually, despite the PEx settings, but I just confirmed by stepping through GPIO_DRV_Init and seeing it configure the directions for the one input (MISO) and the seven outputs (MOSI, MCK, CS, and four MUX bits).

But when I step over GPIO_DRV_SetPinOutput( mux0), where mux0 is an output bit, the corresponding pin J1.11 on the FRDM-K64F does not go high.

Can you suggest anything for me to check?

0 Kudos
366 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Dave:

Set the "Open Drain" setting to disabled in all the pins, unless you have external pull-ups.

0 Kudos
366 Views
dave408
Senior Contributor II

Oh man, how did I miss that...  thank you.

0 Kudos
366 Views
dave408
Senior Contributor II

Yong, disabling tabs view definitely made it easier to figure out how to get fsl_gpio to work.  However, it looks like I cannot have two fsl_gpio components in my project, even though they use different ports.  My "mux" fsl_gpio component uses PORTC, and my "spi" fsl_gpio component uses PORTD.  If I have only one enabled at a time, PEx can generate code.

However, if I have both enabled, I get a PEx error popup when I try to generate code.  It tells me to look in the Problems window for more details.  Then the Problems window tells me to check the Component Inspector for errors.  When I go to the Component Inspector, there are *no* errors.  However, the Components window shows red Xs on each of the fsl_gpio components, but no additional error information.  So I can't figure out how to get both working, and thought that maybe this is a limitation in PEx and I can't used more than one at a time...  ???

0 Kudos
367 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Dave:

I posted a video about using fsl_gpio component in the next link: Video Link : 3195

Apart from the video I would like to clarify some points with you:

- As colleague Filip mentioned, in the fsl_gpio component the device selection (PORTA, PORTB, ...) is not relevant, since the component allows you to allocate any pins from any ports as inputs/outputs.

- You only need one fsl_gpio component, just add all of your required pins to the input and output configurations. In the video I use PORTC for the input button and PORTB for the LEDs, but I could have also added the green LED (which belongs to PORTE) without any extra component.

- I think the GenericBitIO is a custom Processor Expert component created by colleague Erich Styger, right? So we cannot help much with that one.

- If you do not feel comfortable with KSDK yet and would prefer to use the BitIO or BitIO_LDD component, just from the New Project Wizard uncheck the "Kinetis SDK" option. BitIO is part of the legacy Processor Expert components, which will not be available anymore for new Kinetis devices, but for K64 you can still use them. The next is a discussion about this: Re: How do I merge PEx components from PEx DriverSuite into KDS/SDK?

I hope this helps with your confusion.

Regards!

Jorge Gonzalez

View solution in original post

0 Kudos
366 Views
dave408
Senior Contributor II

Jorge, thanks for the clarification.  I'll watch the video.

I'll remove the extra fsl_gpio component.  I don't really need a hotfix for this, I just need to know what the constraints are on components, and now it's crystal clear for me and fsl_gpio.

Thanks for bringing up that point about GenericBitIO.  The problem was that I had started playing with KDS last year and apparently I must have installed Erich's component when I was learning about PEx (from his blog, actually).  So that makes sense now!

I started with KSDK, but after spending too much time trying to get things like C++ and certain components working (that aren't yet working in KSDK 1.1), I have decided to try working with PEx only and avoiding KSDK, if I can.  However, at the moment I'm just learning how to use each peripheral one at a time, in separate projects.  I don't know yet if putting everything together in the end is going to have an issue that can only be resolved by using KSDK.

Perhaps you can tell me if this list of requirements will be an issue for non-KSDK projects?

  • Project 1, ideally MQX but could be BM
    • Target processor: K22F, possibly K02F instead
    • GPIO
    • PWM with FTM 0 & 3
    • QD with FTM 1 & 2
    • SPI
    • I2C
    • UART
  • Project 2 has all of the above peripherals, in addition to:
    • Target processor: K64F
    • Ethernet
    • MQX

Does this all look reasonable?  I have to avoid as many bugs as possible, and it seems like KSDK isn't quite ready yet.

Thank you for your help!

0 Kudos
366 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Dave:

fsl_xxx components are used to configure KSDK static drivers, so you are really not "avoiding" KSDK. To avoid KSDK uncheck "Kinetis SDK" from the New Project Wizard as I mentioned.

About your scenarios, I think you can get around with the available Pre-SDK software enablement, since K22F and K64F are supported by both: legacy Processor Expert components and classic MQX, but at some point you may want to migrate to KSDK. For K02 I am not quite sure though.

Regards!

Jorge Gonzalez

0 Kudos
366 Views
dave408
Senior Contributor II

Ok, thanks.  I had forgotten that all of the MQX work I have done thus far is using MQX for KSDK, and not the separate MQX 4.1.1 installation.

From that post you linked previously, it sounds like I won't be able to use KSDK to get MQX integration and still use the legacy PEx components.  So in this case, I suppose I will need to either use whatever PEx components that are functional along with my own peripheral coding (like what I have had to do for QD support), or I need to punt on KSDK completely and use the separate MQX 4.1.1 installation along with the legacy PEx components.

Does it sound like I'm understanding everything correctly now?  :smileyhappy:  Thank you *so* very much for your detailed answers, and most of all, patience.

0 Kudos
366 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Correct, you understand the concepts better now Dave. The problem is that you got caught in a Kinetis enablement tools transition, for the best we hope, but this has caused a certain amount of confusion. We understand that, sorry for the troubles.

In any case we are here to help and make the learning curve easier and smoother :smileyhappy:.

Regards!

Jorge Gonzalez

0 Kudos
366 Views
dave408
Senior Contributor II

Thanks, I will give disabling Tabs view a try!

0 Kudos