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 [4] 5 6 7
46
µTasker general / why are the packets only 128 bytes long?
« on: December 18, 2009, 06:14:03 PM »
Is there anything in uTasker that would cause the PC (Linux) side of ethernet communications to only send 128 byte length packets?
I've attached a wireshark capture (ip.addr==192.168.10.186).  It shows a test application that just responds with 1024 'x' characters, but only 128 are sent.  I stopped it after the first packet, but it would continue with 128 length packets until all 1024 are sent.

I've never run into this before, so I thought I'd start here.


Thanks,
Aaron

47
µTasker general / writing data to flash
« on: December 01, 2009, 01:41:57 AM »
Mark,

We are using the telnet interface to communicate to our servers and would like to be able to pass base64 data from the server to uTasker and then save it to flash.  This is actually for a firmware upgrade function.  I thought I could base it on some of the code from the ftp.c, but in the case for STOR, after the ptrFile and ucMimeType are set, I don't see where data is actually being written to flash, it looks like the function returns shortly after that.

If you could point me in the right direction that would be great.

Thanks,
Aaron

48
Mark,

Has Freescale updated you on this?  I noticed that the patches section shows 7.1.2a, but the actual download filename still says 7.1.2.  So I wasn't sure if I should stay away from 7.1.2 for now, or what.

Thanks,
Aaron

49
µTasker general / Re: OpenDHCPServer issue
« on: November 11, 2009, 12:26:59 PM »
Mark,

Thank you for looking at this.  Your email was a great help while researching a solution.  I did find the error message in the code.  It turns out that this DHCP server is a secondary server, which means that it relies on the primary server to do the NAK.   There is no option for making it a primary either.  I found another DHCP server by the same author which is much more popular (dual dhcp server), which has the same issue, and multiple people are confused by it's behavior according to its help forum.

Well at least I know now what to look for.  I found a different software: haneWin DHCP Server, which works great!

Thanks,
Aaron


50
µTasker general / OpenDHCPServer issue
« on: November 10, 2009, 04:16:26 AM »
Has anyone used the OpenDHCPServer from SourceForge?
When we run ours we are getting a message regarding the uTasker based devices as follows:
DHCP Request from Client 10:65:a3:00:00:6a () without Discovery, ignored
and no IP address is being assigned to our devices.

Thanks for your help,
Aaron

51
µTasker general / Re: DHCP behaviour
« on: October 28, 2009, 07:19:25 PM »
Mark,

The problem is that the FORCE_INIT clears out the "default IP".  So when dhcp fails (the network has no dhcp server), then the default IP is set to 0.0.0.0, which doesn't allow the unit to work.

My goal was to allow the default IP to stay intact, so when there is no dhcp server our factory programmed default IP can be utilized.  It would be nice to have it operate faster, like FORCE_INIT, but keep the default IP on dhcp failure.


Aaron

52
µTasker general / Re: DHCP behaviour
« on: October 14, 2009, 07:57:53 PM »
Well here is what I found, and did.

Change in application.c in #USE_DHCP:
fnStartDHCP((UTASK_TASK)(FORCE_INIT | OWN_TASK));            // activate DHCP
to
fnStartDHCP((UTASK_TASK)(OWN_TASK));

I found that the FORCE_INIT would clear out the default IP address.

The next step was to handle the case of no network cable plugged in for a while (longer than the 2 minute timeout) after power is applied.
in dhcp.c
Code: [Select]
extern int fnStartDHCP(UTASK_TASK Task){
if (usConnectedToBB & LINK_STATUS){ //only do this if the link is up. {AL}
if ((DHCPSocketNr >= 0) || ((DHCPSocketNr = fnGetUDP_socket(TOS_MINIMISE_DELAY, fnDHCPListner, (UDP_OPT_SEND_CS | UDP_OPT_CHECK_CS))) >= 0)) {
fnBindSocket(DHCPSocketNr, DHCP_CLIENT_PORT);
MasterTask = (Task & ~FORCE_INIT);
if (!(Task & FORCE_INIT) && (uMemcmp(&network.ucOurIP[0], cucNullMACIP, IPV4_LENGTH))) {   // if we have a non-zero IP address we will try to re-obtain it
uMemcpy(ucDHCP_IP, &network.ucOurIP[0], IPV4_LENGTH);        // copy our IP address to the DHCP preferred address
uMemset(&network.ucOurIP[0], 0, IPV4_LENGTH);                // remove the local IP since it may only be used after being validated
ucDHCP_state = DHCP_STATE_INIT_REBOOT;                       // we already have a previous value - we will try to obtain it again
}
else {
ucDHCP_state = DHCP_STATE_INIT;                              // we have none so we must start fresh
}
fnRandomise((4*SEC), E_START_DHCP);                              // perform DHCP state/event after short delay                    
return 0;                                                        // OK
}    
return NO_UDP_SOCKET_FOR_DHCP;                                       // error
} else {
uTaskerGlobalMonoTimer( OWN_TASK, (DELAY_LIMIT)(2*SEC), E_RETRY_DHCP); // try again in 2 seconds{AL}
return LINK_NOT_READY; // return this if the link is not up yet
}
}

// DHCP task
//
extern void fnDHCP(TTASKTABLE *ptrTaskTable)  
{    
    QUEUE_HANDLE PortIDInternal = ptrTaskTable->TaskID;                  // queue ID for task input
    unsigned char ucInputMessage[SMALL_QUEUE];                           // reserve space for receiving messages

    if ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH )) {      // check input queue
        //if ( ucInputMessage[ MSG_SOURCE_TASK ] == TASK_ARP) {
switch (ucInputMessage[ MSG_SOURCE_TASK ]) {     //check which type of message we have {AL}
case TASK_ARP:
// Note that we receive ARP messages only on our attempt to send a test message to a node with our allocated IP address.
// Since DHCP uses broadcast messages until this point there can be no ARP errors
fnRead( PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]); // read the contents
if (ARP_RESOLUTION_SUCCESS == ucInputMessage[ 0 ]) {
if (ucResendAfterArp) {
fnSendDHCP(ucResendAfterArp);
}
else {
fnStateEventDHCP(E_DHCP_COLLISION);                  // this is bad news. We have received IP data from DHCP server but found that someone is already using the address. We have to try again
}
}
else if (ARP_RESOLUTION_FAILED == ucInputMessage[ 0 ]) {
// we have probed to ensure than no one else has the IP address which we have received
// the probing failed which means we can use it - inform application...
fnStateEventDHCP(E_DHCP_BIND_NOW);
}
ucResendAfterArp = 0;
break;
case INTERRUPT_EVENT:   //Here is where the dhcp failure is reported {AL}
switch (ucInputMessage[MSG_INTERRUPT_EVENT]) {
case DHCP_SUCCESSFUL:                                        // we can now use the network connection
break;

case DHCP_MISSING_SERVER:
fnStopDHCP();                                            // DHCP server is missing so stop and continue with backup address (if available)
break;
}
break;
case TIMER_EVENT:
if (ucInputMessage[ MSG_TIMER_EVENT ] == E_RETRY_DHCP) { //{AL} retry DHCP if LINK was down
fnStartDHCP((UTASK_TASK)(OWN_TASK));
} else {
fnStateEventDHCP(ucInputMessage[ MSG_TIMER_EVENT ]);           // timer event
}
break;
        }
    }
}


Then in NetworkIndicators.c I set or clear the bit LINK_STATUS, for link up or link down.

So the operation is now:
If link is down check again in 2 seconds.
If link is up and dhcp responds, use that IP (IP is 0.0.0.0 while waiting for dhcp).
if link is up and dhcp isn't responding (IP is 0.0.0.0 while waiting for dhcp), timeout and use default IP
if link is up and static IP is assigned, use that.


I hope this helps someone.

Aaron

UPDATE:Since everything waits for link to be stable, this does take longer for the system to start.  About 30 seconds, as opposed to the original 10s.

53
µTasker general / Re: DHCP behaviour
« on: October 14, 2009, 06:24:32 PM »
I'm dealing with this same behavior....what was the resolution?


Thanks,
Aaron

54
µTasker general / Re: trying to use fnDelayResetBoard()
« on: October 05, 2009, 10:20:41 PM »
Never mind...I'm a dork! :P

I needed
Code: [Select]
if (ucInputMessage[ MSG_TIMER_EVENT ] == MAC_SET_DELAY_RESET) {
instead of
Code: [Select]
if (ucInputMessage[ 0 ] == MAC_SET_DELAY_RESET) {


Aaron

55
µTasker general / Re: trying to use fnDelayResetBoard()
« on: October 05, 2009, 10:00:10 PM »
It's been a while, since I've touched this code, so I'm sure I'm doing something wrong.
I put the other code mentioned above, back in place.  I now have added a TIMER_EVENT to fnDebug()
Code: [Select]
case TIMER_EVENT:
   fnRead( PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]); // read the contents
            if (ucInputMessage[ 0 ] == E_TIMER_SW_DELAYED_RESET) {
fnResetBoard();
   }
   break;

and added my own function to trigger the case:
Code: [Select]
static void fnUartDelayResetBoard(void){
    uTaskerMonoTimer( TASK_DEBUG, (DELAY_LIMIT)(1*SEC), E_TIMER_SW_DELAYED_RESET );
}

and from fnDoIP() I have:
Code: [Select]
#ifdef USE_PARAMETER_BLOCK                                           // {5}
        else {
            fnDoFlash(DO_SAVE_PARS, 0);    // save the new MAC address
            //fnResetBoard();                     // reset so that it strats with the new values
   //fnDelayResetBoard(); //delay to allow UART to complete, then reset with new values.
     fnUartDelayResetBoard();
        }
    #endif
        break;

I do get to the if statement, but the ucInputMessage[0] value is 47, while E_TIMER_SW_DELAYED_RESET is defined as 131.

Why isn't the message what I have set it to?

Aaron

56
µTasker general / trying to use fnDelayResetBoard()
« on: October 05, 2009, 08:57:20 PM »
Mark,

I'm using the secret command "MAC" for factory configuration.  I've found that after I set the MAC, the system reboots faster than the UART can output the message "\r\nConfiguration saved\r\n". (~23ms)
So I tried removing the static qualifier on fnDelayResetBoard() and called it instead, but then the card never resets.

Code: [Select]
else {
            fnDoFlash(DO_SAVE_PARS, 0);                                  // save the new MAC address
            //fnResetBoard();                                              // reset so that it strats with the new values
   fnDelayResetBoard(); //delay to allow UART to complete, then reset with new values.
any ideas on how to make this work?

BTW, in the simulator, the message is printed fine with the regular fnResetBoard() function call.  I think this is a windows simulator buffering trick though.

Thanks,
Aaron

57
NXPTM M522XX, KINETIS and i.MX RT / Re: port 52233 to 52236?
« on: September 03, 2009, 09:55:48 PM »
What about figuring out how much processing power (MIPS or whatever) is left.  By using this other chip there is a 16.7% reduction in clock speed.  Other than running it through its paces, is there a way to tell if the CPU is waiting a lot, thus indicating a speed reduction may have little or no impact?  Or is 60Mhz just enough for the stack with a  little left over for the user application?

I'm going to do some tests with the 52233 and just reduce the clock speed to 50Mhz by setting
#define  PLL_MUL  10
but it would be nice to be able to have a quantifiable number to talk about.

Any ideas?

Thanks,
Aaron

58
NXPTM M522XX, KINETIS and i.MX RT / port 52233 to 52236?
« on: September 03, 2009, 08:29:51 PM »
Mark,

There are some availability issues with the mcf52233, but we found some mcf52236, which appear to be pin compatible, with the only difference I can find being the 60Mhz vs 50Mhz respectively.  Looking through app_hw_m5223x.h, I see there are #defines for making sure the clocks are correct, but I don't see what needs to be changed in order to use the 50Mhz clock.
Can you provide some guidance?

**reading..reading**

okay, I found these....
Code: [Select]
#define CRYSTAL_FREQ                   25000000                  // 25 MHz oscillator / crystal input
#define PRE_DIVIDER                    5                         // warning: in first silicon this can not be changed!
#define OSCCLK                         (CRYSTAL_FREQ / PRE_DIVIDER)
#define PLL_MUL                        12                        // 60MHz operation

Do I just change the PLL_MUL to 10?  Are there any issues with Ethernet timing that you are aware of, when using this chip?


Thanks,
Aaron

59
µTasker general / Re: Finding device with DHCP IP address
« on: September 01, 2009, 12:32:33 AM »
There is another option....and that is to have the coffee pot initiate the communication.  Of course this requires some additional interfacing: server to accept the coffee pot communication and an interface to the web browser.

Aaron

60
µTasker general / Re: uTasker: strengths and weaknesses
« on: September 01, 2009, 12:05:56 AM »
Support, support, support!
I tried out the Freescale Interniche OS/stack and when I ran into trouble, the replies took days through the forum.  Some issues went unresolved and were never responded to. ???

However Mark's support has been awesome.  He may not want to admit it, but it was like having a co-developer working with me.

Also the uTasker flash footprint is super tiny, yet full featured.  This means more space to store fancy web pages, instead of just a few gimpy text based web pages.

That's my 2 cents.
Aaron

Pages: 1 2 3 [4] 5 6 7