Show Posts
1
NXPTM M522XX, KINETIS and i.MX RT / 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.
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.