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 - alager

Pages: [1] 2 3 ... 7
1
NXPTM M522XX, KINETIS and i.MX RT / Re: mcf52259 FEC RXF ISR stops sometimes
« on: March 20, 2015, 05:03:18 PM »
Mark,

Thanks for the reply.  It turns out that the  issue was actually a bad solder joint on this unit.
Here is a link to the thread on freescale where I was working with Tom on this.
https://community.freescale.com/message/495639?et=watches.email.thread#495639

Although it turned out to be a hardware issue, through the investigation we did find an issue with the MII_SPEED setting, so I'm sure that will improve overall reliability in our products.

Aaron

2
NXPTM M522XX, KINETIS and i.MX RT / Re: mcf52259 FEC RXF ISR stops sometimes
« on: March 17, 2015, 06:59:20 PM »
Mark,

Thanks for the pointers.  Here are some screen shots showing the buffer descriptors and the FEC registers.  One, registers only, from "working" and a full CW screen shot for non-working.  From what I can see (if I'm reading this correctly), there are no dropped frames, and all the receive buffers have the E bit set, so they are empty. But I'm still not getting the interrupt.
If this shows any clues that I'm not seeing, that would be great to know.

Thanks,
Aaron

3
NXPTM M522XX, KINETIS and i.MX RT / mcf52259 FEC RXF ISR stops sometimes
« on: March 11, 2015, 05:13:23 PM »
We have a project where after some unknown event happens, the FEC stops triggering the RXF interrupt.  It could be minutes, could be days before the event happens.  Wiresharking hasn't shown anything suspicious. Tx is still working, in fact, our clue that there is a problem is that the device is refreshing its ARP table on its 20 minute boundary but doesn't listen to the response.
 
Things I've checked when this occurs:
EBERR is 0
RXF is 0
RXB is usually 1, but that mask is not set
ETHR_EN is 1
RDAR is 1
 
 
Also, not every device seems to do this.  Out of 100 devices probably 5-10 exhibit this behavior.
 
Any help in how to trouble shoot this would be great.
Thanks,
Aaron

4
NXPTM M522XX, KINETIS and i.MX RT / Re: mcf52233 clock off by 20% with CW10 (sometimes)
« on: July 21, 2014, 05:12:59 PM »
Mark,

Thanks for the analysis!  I did miss the part (PRE_DIVIDER - 1).  Those HW engineers can make some wily register values at times.  :o

Aaron

5
NXPTM M522XX, KINETIS and i.MX RT / Re: mcf52233 clock off by 20% with CW10 (sometimes)
« on: July 19, 2014, 12:15:27 AM »
Mark,

Yes, you are right, we are using the standard start up files generated by freescale.  Porting our uTasker project over to CW10 was a bit of  a hassle, so we opted to use the standard files.

SYNSR is a volatile:
#define MCF_CLOCK_SYNSR                      (*(vuint8 *)(0x40120002))

Single stepping through the init function while watching the clockout pin, I can see the frequency at 25Mhz, then when SYNCR is set, clockout goes to 40Mhz, and stays there, like it's stable.

Are you aware of any trim values, or anything like that on this chip?

Thanks,
Aaron

6
NXPTM M522XX, KINETIS and i.MX RT / mcf52233 clock off by 20% with CW10 (sometimes)
« on: July 18, 2014, 11:47:59 PM »
We have a mature product that was developed on CW7.  We've ported it over to CW10.4, and have found that some boards, identical in measured 25Mhz xtal input, are running about 20% slower.  40Mhz instead of 50Mhz.
This is causing the uart baud rate calculations to be wrong among other things.
Below is the pll initialization function.  I've checked the LOCK bit in SYNSR and it indicates that the PLL is locked.
 
Code: [Select]
void pll_init(void)
{
  MCF_CLOCK_CCHR =0x05; // The PLL pre divider - 25MHz / 5 = 5MHz
 
  /* The PLL pre-divider affects this!!!
  * Multiply 25Mhz reference crystal /CCHR by 10 to acheive system clock of 50Mhz --> MCF_CLOCK_SYNCR_MFD(3)
  */
 
  MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(3) | MCF_CLOCK_SYNCR_CLKSRC| MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN ;
 
  while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))
  {
  }
}
 
I've tried erasing the chip completely and then re-programming to no avail.  If I load up one of the S19 files that was generated with CW7, then there are no issues with any of the boards.
 
chip markings are different only in the third line:
good: qaaq932
bad: qea1042

Any ideas on how to correct this would be greatly appreciated!
Aaron

7
NXPTM M522XX, KINETIS and i.MX RT / Re: reducing ram footprint
« on: October 12, 2012, 05:14:09 PM »
A few more optimizations.  Turns out that the optimizer is putting
Code: [Select]
const unsigned char cucNullMACIP[MAC_LENGTH] = { 0, 0, 0, 0, 0, 0 };from config.h into .bss because it is initialized to all 0.  I got it to behave as intended by wrapping it in a #pragma
Code: [Select]
#pragma explicit_zero_data on
const unsigned char cucNullMACIP[MAC_LENGTH] = { 0, 0, 0, 0, 0, 0 };   //how to force this into rom?  right now because it's all 0s, it is being put into bss
#pragma explicit_zero_data off
I'm being so picky about this because I'm down to 3 bytes of stack and 12 bytes of heap.  The above change should give me 9 bytes of stack free. 

Aaron

8
NXPTM M522XX, KINETIS and i.MX RT / Re: reducing ram footprint
« on: October 10, 2012, 10:16:46 PM »
Interesting, I'm using VS express 2010 and I don't get any warnings about it.
I found the above example after implementing my own lists, and seeing my ram get sucked up.  So I went searching and only found the one instance in config.h.  It's special to the pointer.  If the lists are just arrays, then things end up in rom as expected.

My code ended up being like this:
Code: [Select]
static const char * const MyStrings2[] = {"$OUTLET",
"$BANK",
0
};
with a pointer to it like this:
Code: [Select]
const char * const *pString;
pString = MyStrings2;
I'm amazed it worked at all actually.   :D

Aaron

9
NXPTM M522XX, KINETIS and i.MX RT / reducing ram footprint
« on: October 10, 2012, 09:01:54 PM »
I'm not sure how the other platforms handle this, but in CW 7.2 the following code still uses 24 bytes of ram, as verified by the xMAP file.
Code: [Select]
const CHAR *cMimeTable[] = {                                         // keep the ordering in the table to match the MIME type defines below!!
        (const CHAR *)"HTM",                                             // HTML file - will be interpreted by web server
        (const CHAR *)"JPG",                                             // JPG image
        (const CHAR *)"GIF",                                             // GIF image
        (const CHAR *)"CSS",                                             // CSS Cascading Style Sheets
        (const CHAR *)"JS",                                              // Java script
        (const CHAR *)"BIN",                                             // binary data file
        (const CHAR *)"TXT",                                             // text data file
        (const CHAR *)"ICO",                                             // icon
        (const CHAR *)"???",                                             // all other types will be displayed as unknown
    };
Adding const after the *, not only forces the pointers into flash, but also the values being pointed to:
Code: [Select]
const CHAR * const cMimeTable[] = {                                         // keep the ordering in the table to match the MIME type defines below!!
        (const CHAR *)"HTM",                                             // HTML file - will be interpreted by web server
        (const CHAR *)"JPG",                                             // JPG image
        (const CHAR *)"GIF",                                             // GIF image
        (const CHAR *)"CSS",                                             // CSS Cascading Style Sheets
        (const CHAR *)"JS",                                              // Java script
        (const CHAR *)"BIN",                                             // binary data file
        (const CHAR *)"TXT",                                             // text data file
        (const CHAR *)"ICO",                                             // icon
        (const CHAR *)"???",                                             // all other types will be displayed as unknown
    };
Be sure to update the externs for this also.

Aaron

10
µTasker general / fnDNSListner() returning an unknown errror sometimes
« on: April 30, 2012, 07:53:08 PM »
We are starting to accumulate customer calls that turn out to be a lack of DNS resolution.  However, as shown in the function below, we are hitting the "Some Unknown Error" case, and no number is printed out.  Of course this is something that we are not able to reproduce here, so I'm looking for ideas on what sorts of things can cause this.

Code: [Select]
//local dns function for nslookup via the telnet client.
static void fnDNSListner(unsigned char ucEvent, unsigned char *ptrIP){
CHAR cBuf[21];

    switch (ucEvent) {
case DNS_EVENT_SUCCESS:
uStrcpy(cBuf, "DNS answer: ");
fnDebugMsg(cBuf);
//fnDebugMsg("DNS answer: ");
fnIPStr(ptrIP, cBuf);
break;
default:// DNS error message
uStrcpy(cBuf, "DNS Error: ");
fnDebugMsg(cBuf);
if (ucEvent == DNS_ERROR_NO_ARP_RES) {
uStrcpy(cBuf, "DNS_ERROR_NO_ARP_RES");
}else if (ucEvent == DNS_ERROR_TIMEOUT) {
uStrcpy(cBuf, "DNS_ERROR_TIMEOUT");
}else if (ucEvent == DNS_ERROR_GENERAL) {
uStrcpy(cBuf, "DNS_ERROR_GENERAL");
}else if (ucEvent == DNS_OPCODE_ERROR) {
uStrcpy(cBuf, "DNS_OPCODE_ERROR");
} else {
uStrcpy(cBuf, "Some Unknown Error:");
fnDebugMsg(cBuf);
fnDebugDec(ucEvent, 0,cBuf);
}
break;
    }
fnDebugMsg(cBuf);
fnDebugMsg("\r\n");
}

Thanks,
Aaron

11
NXPTM M522XX, KINETIS and i.MX RT / Re: win7 + vc2010 simulator dies when writing to flash
« on: March 07, 2011, 07:27:47 PM »
That worked! ;D

Thanks,
Aaron

12
NXPTM M522XX, KINETIS and i.MX RT / Re: win7 + vc2010 simulator dies when writing to flash
« on: March 07, 2011, 06:12:28 PM »
Mark,

That wasn't it.  I upped it from 100 to 400, no change.

I did notice that I'm getting a warning that I didn't get before:
1>  M5223X.c
1>c:\projects\utasker_sp8\trunk\hardware\m5223x\m5223x.c(2012): warning C4789: destination of memory copy is too small
1>c:\projects\utasker_sp8\trunk\hardware\m5223x\m5223x.c(2016): warning C4789: destination of memory copy is too small
Code: [Select]
  case 1:
        iInts |= CHANNEL_1_SERIAL_INT;                                   // simulate interrupt
        ucTxLast[1] = UTB_RB_1;                                          // back up the data written so that it can't get lost when rx data uses the simulated register {27}
        break;
    case 2:
        iInts |= CHANNEL_2_SERIAL_INT;                                   // simulate interrupt
        ucTxLast[2] = UTB_RB_2;                                          // back up the data written so that it can't get lost when rx data uses the simulated register {27}
        break;not sure if that is a red herring or not.


Also, here are more details on the output of the error:
First-chance exception at 0x004eb380 in uTasker.exe: 0xC0000005: Access violation.
Unhandled exception at 0x004eb380 in uTasker.exe: 0xC0000005: Access violation.
The program '[5292] uTasker.exe: Native' has exited with code -1073741819 (0xc0000005).
Code: [Select]
Autos
*ptrWord 4294967295 unsigned long
fnRAM_code 0x004eb380 ulProgSpace void (void)*
- ptrWord 0x00514600 unsigned long *
4294967295 unsigned long
ucCommand 64 '@' unsigned char
ulWord 0 unsigned long

I'm lost on this one, if you have any more ideas, let me know.

Thanks,
Aaron

13
NXPTM M522XX, KINETIS and i.MX RT / win7 + vc2010 simulator dies when writing to flash
« on: March 04, 2011, 01:27:39 AM »
Mark,

I just tried updating the web files (using ftp) while running the simulator, and the simulator dies with an "access violation" on this line in M5223X.c.
fnRAM_code();                                                        // execute from SRAM

I erased the flash_M5223x.ini file, to start from scratch, but it still fails.

Any ideas on what I should look at?

Thanks,
Aaron

EDIT: By the way I'm using the last VC2010 project files for 1.3 that you posted here: http://www.utasker.com/forum/index.php?topic=1111.0
I also get the same error if I telnet to the simulator and do a "factory restore" int he admin menu, or "save" in the LAN configuration menu.

14
µTasker general / Re: uTasker + Windows 7 64-bit + VC 2010
« on: February 22, 2011, 11:30:02 PM »
I'm such an idiot.  That was the problem...

thanks.

15
µTasker general / Re: uTasker + Windows 7 64-bit + VC 2010
« on: February 22, 2011, 10:23:46 PM »
Mark,

I've made the changes noted in this thread and I even tried turning off tx and rx offloading in the NIC  card, but I am not seeing any DHCP requests being sent, even though I'm hitting the
else {                                                               // or broadcast
        fnSendUDP(DHCPSocketNr, (unsigned char *)cucBroadcast, DHCP_SERVER_PORT, (unsigned char *)&tUDP_Message.tUDP_Header, DHCP_BUFFER, OWN_TASK);
    }
in dhcp.c

I made the changes to ip.c, tcp.c udp.c icmp.c, but I still am not able to run the simulator....
Any ideas?

EDIT: I just noticed this thread is about 64bit win7, I'm running 32bit win7.  Just in case that makes a difference.

Thanks,
Aaron

Pages: [1] 2 3 ... 7