Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kaflick

Pages: [1] 2
1
NXPTM M522XX, KINETIS and i.MX RT / Re: Bootload problem
« on: May 30, 2012, 01:04:01 AM »
We are using both the on chip file system and the off chip file system.  Our parameter and configuration files are stored on the on chip file system.  They are large and complicated file that are generated by special configuration programs written for our sales people.  These are then loaded by ftp.  Our program is so large that it has to be written into the spi flash.  I believe that with ftp the special case file HS.bin is stored on the spi flash to be used for the new program.  Is that the only file name that is store on the spi flash?  Can I use another file name that locates it at the beginning of the spi flash?
Or do I need to calculate the offset for the H file and add it to the offset the bootloader uses to locate the header?
I do not have a setup for the simulator and we are not using the web server or your parameter functions since everything has to happen over ftp.

Thank you for your help
Keith A Flick

2
NXPTM M522XX, KINETIS and i.MX RT / Re: Bootload problem
« on: May 29, 2012, 08:36:56 PM »
It looks like the bootloader is reading from 0x80005 for the header.

Is that where it should be reading from?

3
NXPTM M522XX, KINETIS and i.MX RT / Bootload problem
« on: May 29, 2012, 08:26:11 PM »
I am trying to get the bootloader working with my application and the bootloader location is apparently different from where the application puts the new code.  I am using the spi flash for the download and I am downloading the file over ftp (using the HS.bin name).  The download seems to work fine, it does not show up in the on-chip filesystem but when I get the file from ftp it compares exactly to what I sent.  When the bootloader reads the header all of the values are wrong so I assume that it is reading in the wrong place.  Where is the write done in the application so I can look at the values there and compare with the bootloader?

If you have a writeup on the values used for the locations please direct me to that too.

Thank you,
Keith A Flick

4
NXPTM M522XX, KINETIS and i.MX RT / Re: iic problem
« on: April 13, 2012, 06:03:24 PM »
I have now restored the fnApplication to it's normal configuration in
TaskConfig.h.  I have added a control task that gets called every 1 ms
that does our control and communication over iic.

The first time the write to iic is called it hangs on the while in the
116 code.  When I go to the registers to see what is happening I
cannot read anything at addresses in the 0x40000300 range (I get
all ***** in codewarrior).  This looks like it is not initialized
correctly.

I have followed it through the init routine and it seems OK, for instance
it is calling the powerup so I would expect to be able to read those addresses.
 any suggestions on what to look at next?

Keith Flick

5
NXPTM M522XX, KINETIS and i.MX RT / Re: iic problem
« on: April 13, 2012, 03:01:01 PM »
I moved the call to write to the iic from before the while
that processes the input queue to the very end of fnApplication
and now it runs for a while (20 or 30 ms) and then gets an
undefined interrupt so I''ll take a look at what is happening and get back
to you if I continue to have a problem.

Thank you
Keith Flick

6
NXPTM M522XX, KINETIS and i.MX RT / Re: iic problem
« on: April 13, 2012, 02:51:59 PM »
I have the iic running, it works fine.  It is being called a from a 1ms timer.

When I change the app to be called at a 1 ms period from TaskConfig.h
and move my call to :

     fnWrite(IICPortID, (unsigned char *)&(output_i2c.data.address), sizeof (comStruct));

from the 1MS timer routine (which I don't have any more) to the base fnApplication
routine it hangs on the first call.  That is the only change between the two versions of
code.

Is there a problem with changing the base fnApplication routine called every 1ms, does it
need to be called more often?  (I just modified your fnApplication routine to add my code.)

What else should I look at?


7
NXPTM M522XX, KINETIS and i.MX RT / iic problem
« on: April 13, 2012, 01:21:00 AM »
I have a problem with the iic routine.  I changed my application from running on a 1ms
timer (which seemed very irregular) to being called every 1ms in TaskConfig.h (which
seems very regular) and everything works fine except the iic which waits forever in the
new lines labeled 116 in fnTxIIC (specifically on the while).  It never comes out.

I made sure it was being set up by getting through fnConfigIIC and it looked OK.

What should I look at?

Keith Flick

8
O.K.  It looks just like the previous description.  QUEUE_TRANSFER fnStartEthTx(QUEUE_TRANSFER DataLen, unsigned char *ptr_put)) is being called where you would expect it to be called.  In the EIP routine that sends the UDP message it calls fnSendUDP which calls fnSendIP which call fnWrite one or more times and finally calls fnWrite(Ethernet_handle, 0, 0) which ends up calling fnStartEthTx before it returns up through fnSendUDP which returns a positive integer which is >0.  The sequence number is correct in the buffer.  I ran it with both systems being reset which caused the sequence number to be the same and then I only reset the uTasker system which caused them to be offset by 9291 just to make sure I wasn't displaying the wrong sequence number.  It looks like the correct data is being written to the hardware at the correct time.  I have a request in to Freescale to see what they have to say.


9
I'll do that and let you know what I find.

10
I was using a dumb hub at 10mb (no smarts at all, just the wires connected together electronically).

At 100mb I was directly connected with the robot controller connected to our system without any hub or switch with wireshark running on the robot controller.

In neither case was there anything external that could be slowing down our transmissions.

The time difference at the end of the one sequence was the 40 seconds I mentioned previously, the system logged receiving packet 13,875 and sending packet 13,875 at the same time.  Wireshark saw Robot controller packet 13,875 and uTasker packet 13,140 at the same time and robot controller packet 13,140 42 seconds previously (at the same time as uTasker packet 12442, robot controller 12442 was from 35 seconds earlier).  All of the packets were logged synchronously, from 1 through 13,875 so the uTasker system should have sent them at the same time.

11
It's not queuing in the EIP stack, I made sure of that by logging the send after the return from fnSendUDP.  I'm not getting any errors, it's logging the receives and the sends together but there is up to a 40 second delay on the wire.  It starts out in sync and falls farther and farther behind.

Do you have any suggestions on anything else to try?

Keith Flick

12
In regards to the EIP software we are using a package from Real Time Automation.  It was horribly expensive (IMHO) but it was purchased before I was involved and they didn't ask my opinion :-).  I do believe that it was just about the only choice when they purchased it (around 2004 I believe) for a different project.  That project didn't go anywhere so when the previous one that I worked on started they said "Here use this.".  They could have had some better documentation but I think they assumed that anyone who used it would be EIP gurus (which I certainly wasn't.).  I believe that the current packages from RTA are much more reasonable in price but I was only told this is passing and wasn't given any details.  We did manage to get it to work under uTasker but it was obviously aimed at a PC implementation on a system with infinite memory compared to our systems.  In fact I was told by another user that it was impossible to get it and an OS to run on a system with 32k of ram :-).  It is nice having our HUGE 64K of ram now.

I am hoping to work with the free packages available on Sourceforge or from the ODVA website but I have not been able to yet.  I have not found anyone who has used them on an actual project yet.

Keith Flick

13
I have changed some timer values (to change the communication rate)  to see what that did (not much).

Previously I had a 10 mb Ethernet Hub with three system plugged in, our controller(uTasker), the robot controller (Windows Vista) and the computer I was running wireshark on (XP).

I had anywhere from 10 to 60 seconds of delay between synchronous reads and writes (on the uTasker system) on that system.

I had changed it to eliminate the hub and the XP computer so I could test it with 100mb direct connection between the robot controller system and the uTasker system (I don't have a 100mb switch).  This arrangement gave me 13,875 reads and writes on the uTasker side, all nicely synchronous (no missing packets or any variation in spacing).  The last two packets wireshark (now running on the robot controller system) read were robot controller packet 13,875 and uTasker packet 13,140.  Looking back to the robot controller packet 13,140 gives about 42 seconds of delay.

Looking ate these 735 packets (at 32 bytes per packet) gives about 23k of space which is close to the free space on our system, there isn't any way they are being stored in stack space or heap waiting to be written?

Is there anything that I should be setting up in the Ethernet config that may effect priorities or timing?

Still looking.

Keith Flick

14
Hello,
  We are starting another EIP project with the 52259 and are to the point where we are running the system with a robot controller that also commands our system through EIP (Ethernet Industrial Protocol).  Everything works correctly except the sends of our half of the communications are delayed.  I am logging when we receive an incoming communication and when we send an outgoing communication (there is a sequence number in EIP which makes this easy).

At the beginning of the communication stream the numbers of incoming communications and outgoing communications are logged together and appear together on the ethernet (using wireshark).  As the communications continue our outgoing communications fall farther and farther behind.  After a while our communications stop.  At this point we have logged receiving and sending communications together but wireshark reports our output messages are around 1000 messages behind the incoming messages.  In other words we have received message 10000 and sent message 10000 but the messages wireshark has seen are incoming message 10000 and outgoing message 9000 which were adjacent on the wire.  These numbers do seem to be about correct, we fall behind at just about a 1 per 10 rate.

No errors are reported by any of the calls to uTasker in sending these messages and I have added extra buffers to see if it made a difference (it did not).

The Ethernet does not seem to be too busy to allow sending at the correct rate (they are only 32 bytes long and sent every 50 ms) and this is the same rate as our old system (on the 52235) so we have a faster processor with twice as much memory but the Ethernet can't seem to keep up.

Any suggestions?

Thanks for your attention
Keith Flick

15
I have found the problem in the Interrupt driver in the slave.

One of the status bits had the opposite polarity of what I thought.

If anyone would like a working chunk of I2c Slave interrupt driver here it is:



static __interrupt__ void _IIC_InterruptSlave(void) // I2C0 interrupt
{
   char junk;
   
    I2SR&=~IIC_IIF;     // clear the interrupt flag
    if(I2SR&IIC_IAL) {
       I2SR&=~IIC_IAL;   //   If IAL (arbitration lost) set, clear it
       if(I2SR&IIC_IAAS) {
          buffOffset=0;
       } else return;
    }
    if(I2SR&IIC_IAAS) { // IAAS is set, received our slave address
       if(I2SR&IIC_SRW) { //   if SRW set, tx mode
      I2CR|=IIC_MTX;   //   Set hardware to tx mode
          buffOffset=0;   //   Init buffer address
          I2DR=buf[buffOffset++];   //   Send the first character
       } else { //   rx mode   
      I2CR&=~IIC_MTX;   //   Set hardware to rx mode
          buffOffset=0;   //   Init buffer address
          junk=I2DR;   // Do a dummy read
     }
          
    } else {   //   IAAS not set, in the middle of communication
       if(I2CR&IIC_MTX){ //   If in tx mode
          if(I2SR&IIC_RXACK){   //   Failed to receive an ACK?
               I2CR&=~IIC_MTX;   //   Set hardware to rx mode
             junk=I2DR;   // Do a dummy read
          }else {   // Not done transmitting data
              I2DR=buf[buffOffset++];   //   Send the next character
          }
       }else {   //   If in rx mode
           buf[buffOffset++]=I2DR;   // Read the next character
         
       }
       
    }
}

Here is the setup routine for it:

//
// Configure the IIC hardware
//
void fnConfigIICSlave(IICTABLE *pars)
{
    unsigned char ucSpeed;
    POWER_UP(POWER_I2C);                                                 // enable clock to module {46}
    PASPAR |= (AS_I2C_SCL_0_FUNCTION | AS_I2C_SDA_0_FUNCTION);           // configure the SDA and SCL pins on AS

    // The calculation of the correct divider ratio doesn't follow a formular but is best taken from a table.
    // The required divider value is ((BUS_CLOCK/1000)/pars->usSpeed). Various typical speeds are supported here.
    switch (pars->usSpeed) {                                             // {31}
    case 400:                                                            // high speed IIC
    #if BUS_CLOCK > 60000000                                             // 80MHz
        ucSpeed = 0x32;                                                  // set about 400k with 80MHz bus frequency
    #elif BUS_CLOCK > 50000000                                           // 60MHz
        ucSpeed = 0x0d;                                                  // set about 400k with 60MHz bus frequency
    #elif BUS_CLOCK > 40000000                                           // 50MHz
        ucSpeed = 0x0b;                                                  // set about 400k with 50MHz bus frequency
    #else                                                                // assume 40MHz
        ucSpeed = 0x0a;                                                  // set about 400k with 40MHz bus frequency
    #endif
        break;
    case 100:
    default:                                                             // default to 100kHz
    #if BUS_CLOCK > 60000000                                             // 80MHz
        ucSpeed = 0x3a;                                                  // set about 100k with 80MHz bus frequency
    #elif BUS_CLOCK > 50000000                                           // 60MHz
        ucSpeed = 0x15;                                                  // set about 100k with 60MHz bus frequency
    #elif BUS_CLOCK > 40000000                                           // 50MHz
        ucSpeed = 0x37;                                                  // set about 100k with 50MHz bus frequency
    #else                                                                // assume 40MHz
        ucSpeed = 0x36;                                                  // set about 100k with 40MHz bus frequency
    #endif
        break;

    case 50:
    #if BUS_CLOCK > 60000000                                             // 80MHz
        ucSpeed = 0x3e;                                                  // set about 50k with 80MHz bus frequency
    #elif BUS_CLOCK > 50000000                                           // 60MHz
        ucSpeed = 0x19;                                                  // set about 50k with 60MHz bus frequency
    #elif BUS_CLOCK > 40000000                                           // 50MHz
        ucSpeed = 0x3b;                                                  // set about 50k with 50MHz bus frequency
    #else                                                                // assume 40MHz
        ucSpeed = 0x3a;                                                  // set about 50k with 40MHz bus frequency
    #endif
        break;
    }
    I2FDR = ucSpeed;
    I2CR = (IIC_IEN);                                                   // enable IIC controller and set slave mode
    IC_ICR_0_17 = IIC_INTERRUPT_PRIORITY;                                // define interrupts level and priority
    fnSetIntHandler(IIC_VECTOR, (unsigned char *)_IIC_InterruptSlave);        // enter the handler routine
    IC_IMRL_0 &= ~(IIC_PIF_INT_L | MASK_ALL_INT);
    I2CR|=IIC_IIEN;      //   Enable interrupts
}

Feel free to use it.  You might want to put it in the i2c doc as an example.

The read routine in the application loop works to.  Here it is:

       if (fnMsgs(IICPortID) != 0) {                                        // if IIC message waiting
           while ((Length = fnRead(IICPortID, ucInputMessage, MESSAGESIZE)) != 0) {
            memcpy(&input_i2c.count,ucInputMessage,Length);
           }
       }

Keith Flick

Pages: [1] 2