Author Topic: GPIO issue on FRDM-64F  (Read 260 times)

Offline sullivanag

  • Newbie
  • *
  • Posts: 7
    • View Profile
GPIO issue on FRDM-64F
« on: May 23, 2019, 02:11:29 PM »
Hello uTasker community,

I am pasting a question below from a colleague.  We are evaluating uTasker for a little in-house project in our lab.  We are using the opensource version from github.  Question below:

I am using uTasker with an NXP FRDM-K64F processor board. Attached to the FRDM-K64F board is some custom hardware (shift registers) to retrieve serial data from an external device. I am using twelve GPIO pins to interface to the external circuit (3 SELECT Signals, 1 READ Signal, and 8 data bits).  These signal pins are mapped as GPIO on several K64F ports (Port B - Bits 9, 18, 19, 23) and (Port C - Bits 0, 1, 5, 7, 8, 9, 16, 17). These pins map to the pins on the J1 I/O Header of the FRDM-K64F board. An additional pin is used as an interrupt (Port C – Bit 2) to signal when data is present and ready to be read. The circuit and it’s interface software have been tested and work flawlessly by itself. However, when combined with uTasker and generating Ethernet traffic, a consistent problem occurs. When reading data from the shift registers, sometimes several of the bits are the wrong state (Port C bit 0 and Port B bit 18) and it’s repeatable.

Could  uTasker be using some of the bits in Ports B and C creating a conflict with the operation of our circuit?


Essentially what is happening is that two of our GPIO pins that we are using sometime, but consistently, have are in the wrong state.  We are wondering if maybe something in the uTasker code is also using some of the same Port and Bits we are using.  I am reasonably sure I have disabled everything in the default uTasker configuration.  No file system, no flash, no usb, no i2c, etc.  We are only seeing an issue when reading from (Port C bit 0 and Port B bit 18).  I have been looking through the code trying to determine if uTasker is also using either of these Port/BITS and conflicting with our code.  Its a lot of code to look through, I was hoping someone may have the answer for me.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2983
    • View Profile
    • uTasker
Re: GPIO issue on FRDM-64F
« Reply #1 on: May 24, 2019, 03:32:58 PM »
Hi

I don't see that PortC-0 or PortB-18 are used by any FRDM-K64F code.
There are also two defines in config.h that can be used to ensure that ALL peripheral and GPIO reference code is disabled:

//#define REMOVE_PORT_INITIALISATIONS                                    // remove port initialisation from demonstration to ensure that port configurations don't conflict with specific application developments (exception is blink LED)
//#define NO_PERIPHERAL_DEMONSTRATIONS                                   // disable peripheral demonstration code (ADC/I2C/CAN/port interrupts/etc.) so that they can't interfere with new application developments


When these are disabled the only GPIO that will be used is the one used to flash the green LED (PortE-26).

Note also that if the project can be run in the simulator the state of all ports and peripherals can be checked and maybe you can see something there.

In any case I don't think that there will be uTasker code interfering. Check also the additional circuits on the board to see whether there is something that can drive the lines if not held in a certain state (using jumper setting or controlled by other GPIO outputs).

Good luck

Regards

Mark


Offline sullivanag

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: GPIO issue on FRDM-64F
« Reply #2 on: May 29, 2019, 03:31:38 AM »
Mark,

We found the issue, and it is now working perfectly.  It was a race condition.  We have an external custom board that has various IC's that capture serial data and stores it in three 8-bit shift registers.  We defined 8 pins on the K64F as GPIO.  There is a control signal we send to our custom board that allows us to select which shift register is connected to our GPIO pins. 

To read all of the data we do these steps:

- select shift register one
- read GPIO pins
- select shift register two
- read GPIO pins
- select shift register three
- read GPIO pins

We had all of this code working great using the NXP SDK previously, but our LAN interface could not keep up with the data rate needed.  When we switched to uTasker, LAN worked great, but reading GPIO pins was faulty.  What we discovered was that our code to select a switch register and GPIO read was happening much more quickly in uTasker. 

In other words, we select shift register, then read our GPIO pins.  The select and read happens so quick, that the GPIO read was happening before all of the GPIO pins were being set to the value held in the shift register.  We just needed to add a tiny delay between shift register select and pin read.

Our guess is that when using the SDK, we call a library function to read from a port.  In uTasker we use the port macros, which is not a function call, but simply reads from an address pointer.  Our code worked in the SDK, because the overhead of calling a function (push return address on stack, save registers, restore registers, etc.) was adding enough delay before we read the GPIO pins.

So, all of that said, I think our application is complete.  Thank you again. 

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2983
    • View Profile
    • uTasker
Re: GPIO issue on FRDM-64F
« Reply #3 on: May 29, 2019, 03:05:24 PM »
Hi

Thanks for the feedback.

Yes, the port macros are designed to have lowest possible overhead to achieve fastest possible speed.
To slow things down when interfacing to external HW that needs setup and hold times I tend to repeat the instructions a few times until the required times are obtained:
Eg. in parallel LCD interface:
#define O_SET_CONTROL_LOW(x)    _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _CLEARBITS(C, x); _SIM_PORTS

As you stated, it is probable that your original library code was using subroutines (and maybe without code optimisation enabled), which can take a lot more time, and so not show a race state. There is however always a risk in such cases that a new compiler version or change to optimisation settings (or if the library update declares such functions as in-line functions) that a project will then stop working correctly.

Therefore I think that the macro method is generally the safest since it will not be able to change with new compiler versions and such, even if it caused you a problem in this case; that is, it actually exposed critical timing related code that could have broken at some point anyway....a sort of time bomb, which you no longer have ;-)

Regards

Mark

Offline sullivanag

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: GPIO issue on FRDM-64F
« Reply #4 on: May 29, 2019, 05:06:31 PM »
Great advice Mark, thank you for the input.