Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: GPIO issue on FRDM-64F

« on: May 29, 2019, 05:06:31 PM »

Great advice Mark, thank you for the input.

2

NXP^TM M522XX, KINETIS and i.MX RT / Re: GPIO issue on FRDM-64F

« 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. 

3

NXP^TM 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.

4

NXP^TM M522XX, KINETIS and i.MX RT / Re: issue prioritizing interrupts

« on: May 23, 2019, 01:29:25 AM »

Mark,

I have updated my original post on the NXP community forums.  Thank you again. 

Andy

5

NXP^TM M522XX, KINETIS and i.MX RT / Re: issue prioritizing interrupts

« on: May 15, 2019, 02:38:46 AM »

Mark,

I used option 1, which was to call uEnable_Interrupt() at the start of our PIT interrupt.  Analyzing both interrupt timings on a scope shows them behaving exactly how they should.  I am currently playing around with the opensource version of uTasker.  You created a demo for me maybe 6-8 weeks ago.  I had posted on the NXP forums about about needing to send TCP data (57 byte structures) at a 20 millisecond rate.  That is how I found out about uTasker.

The TCP code took me a little while to understand, as I am used to Berkely sockets.  My LAN interface is working great now.  I am very impressed with all of the features of uTasker.  uTasker has saved me a lot of time.  What a great project!

-Andy

6

NXP^TM M522XX, KINETIS and i.MX RT / Re: issue prioritizing interrupts

« on: May 14, 2019, 06:50:55 PM »

Mark,

Thank you for the quick reply.  That was the issue.  My interrupts are triggering perfectly now.  I have limited embedded programming experience, but I am learning. 

-Andy

7

NXP^TM M522XX, KINETIS and i.MX RT / issue prioritizing interrupts

« on: May 14, 2019, 04:33:12 PM »

Hello,

I am having an issue with prioritization of two interrupts.  The higher priority interrupt is being delayed by the lower priority interrupt.  I have included the code below.  Hopefully someone can point out my mistake.  One interrupt is on a PIT timer that we call the Real Time (RT) interrupt.  It simply increments a counter and toggles an LED on/off periodically.  The other interrupt (Serial Data - SD) is triggered on the falling edge of a GPIO pin.  It is critical that when the SD interrupt triggers, that we interrupt to grab data from other pins.  This is not happening.  If the RT Interrupt is processing, and the SD interrupt triggers, it is delayed until the RT interrupt completes.

I'll post code below.  That interrupt routines are just contain demonstration code.  They do simple LED toggles and we added delays so our oscilloscope could catch them.

I'll try to emphasize this issue below using 0's and 1's.  The SD interrupt should trigger uniformly.  The RT interrupt should not delay the SD interrupt.

RT  00000000111100000000111100000000111100000000

SD  01010101000101010010000010101010000010101010


If anyone can shed some light on this, it would be very helpful.  Oh, We are using the Kinetis K64F BTW.


**********************************************************

RT interrupt code:

PIT_SETUP pit3_setup;

pit3_setup.int_type = PIT_INTERRUPT;
pit3_setup.int_handler = RealTimeInterrupt;
pit3_setup.int_priority = 11;
pit3_setup.ucPIT = 3;                           // use PIT channel 3
pit3_setup.mode = PIT_PERIODIC;                     // periodic PIT interrupt
pit3_setup.count_delay = PIT_MS_DELAY(10);            // 10 ms delay

fnConfigureInterrupt((void *)&pit3_setup);            // enter interrupt for PIT3


void RealTimeInterrupt( void )
{
   char a[10000];
   short i;

   GreenLED( ON );

//   This is a small delay (approx 2.5 msec) for the oscilloscope to work properly!
   for( i = 0; i < 10000; i++ ) {
      a = 0;
   }

   GreenLED( OFF );

}

****************************************************************

SD interrupt code:

INTERRUPT_SETUP SD_Interrupt_setup;

SD_Interrupt_setup.int_priority   = 10;
SD_Interrupt_setup.int_port       = PORTC;
SD_Interrupt_setup.int_port_bits  = PORTC_BIT2;
SD_Interrupt_setup.int_port_sense = IRQ_FALLING_EDGE;
SD_Interrupt_setup.int_handler    = BOARD_INTREQ_IRQ_HANDLER;

fnConfigureInterrupt( (void *)&SD_Interrupt_setup );

void BOARD_INTREQ_IRQ_HANDLER( void )

void SerialDataInterrupt( void )
{
   BlueLED(ON);

   char a[10000];
   short i;

   for( i = 0; i < 1000; i++ ) {
      a = 0;
   }

   BlueLED(OFF);
}