Messages

16

µTasker general / Re: Looking for string to unsigned short code (ansi c).

« on: May 30, 2008, 09:47:23 AM »

Thanks, that worked out great.

JD

17

µTasker general / Looking for string to unsigned short code (ansi c).

« on: May 26, 2008, 09:40:20 AM »

Can anybody point me to or like to share code for string to unsigned short (16bit) routine?  this will be for reading an edit box from a web page to configure a tcp port number.

18

NXP^TM M522XX, KINETIS and i.MX RT / Re: P+E multilink debugger/flash setup for M52235EVB and Codewarrior V.70

« on: May 26, 2008, 01:50:20 AM »

i had previously read a bit of that earlier topic but as it sounded like you were able to erase and flash so it didnt quite sound like the same problem. I'll admit that i have no idea at least in my case what the difference is between converting a project and starting a new project with imported files from the old one.

19

NXP^TM M522XX, KINETIS and i.MX RT / Re: P+E multilink debugger/flash setup for M52235EVB and Codewarrior V.70

« on: May 20, 2008, 03:33:33 PM »

Thanks. I beleive the configuration you described was one that i tried but didnt work.

I ended up having to wizard a new project. Seeing that i could now erase the flash properly i copied the uTasker files into the new project. It appears to have erased and flashed ok and ftp and web/http are working.

For anyone else doing this you can:
- disable or delete MCUinit.c and MCUinit.h if it gets generated
- disable the .a files in the "Libs" group folder
- disable or delete startcf.h and startcf.c if they get generated
- ive left cfm.c until i figure out what it does
-disable or delete support_common.h

use uTasker's:
Startup.s
flash_config.s
M5223X.c
M5223x.h

- delete or disable the generated linker (.lcf) file for FLASH/ROM
 grab the .lcf file from the uTasker project where all the other files were copied from and make that the lcf file for this project.

dont forget to enable the added or replace files with the "dot" in the target column.

There's also a bunch of target settings like precompiler defines etc which can be copied off the other uTasker project.

The other flash programming settings are as Mark has indicated.

JD

20

NXP^TM M522XX, KINETIS and i.MX RT / Re: Compiler V7 limitation!!??

« on: May 16, 2008, 05:16:17 PM »

Had the same problem.
I installed CW7.0 off the CD that came with the M52235EVB and got the same 32 file limitation message.

I then uninstalled it, downloaded the latest one off the freescale site and installed that and didnt get the restriction message after that.

And as a side note, the P&E usb multilink debugger would not make any connections at first attempt but uninstalling the P&E drivers i had installed for other CW using the hcs08/hcs12 BDM and then installing the latest drivers fixed this issue (after several PC resets due to driver installation).

John Dowdell

21

NXP^TM M522XX, KINETIS and i.MX RT / P+E multilink debugger/flash setup for M52235EVB and Codewarrior V.70

« on: May 16, 2008, 05:08:46 PM »

I wonder if anyone has a step by step for setting up utasker for the P&EMicro colfire multilink bdm for codewarrior V7.0?
i'm not sure which initialisation file (.cfg) or flash settings file (.xml) i should be using. 

current settings:
flash settings file: MCF52235_INTFLASH.xml
Target processor: 52235
Connection: PEMICRO_USB
device:CFM_MCF55235
initialisation file:M52235EVB.cfg   (doesnt do anything without custom settings)

Trying to erase settings gets me:
 "Downloading Flash Device Driver ..."
--something flashes up too fast to read--
"Initializing...  "
 "Reading init return status   " 
"Run the target  "
"System clock check checking ... "
"Error:  System clock check failed  See Details for additional information."


Details:
 Flash driver reports the following error(s):  Operation Unsupported  Timed Out  Verify failed


Ideas anyone?

John Dowdell

22

Freescale^TM MC9S12NE64 / Re: Activity LED timing

« on: May 06, 2008, 10:47:25 AM »

can i assume that the DPMD flag in the PHY_PSR register is correct for both auto neg and manual?

23

Freescale^TM MC9S12NE64 / Re: Activity LED timing

« on: May 06, 2008, 09:33:51 AM »

Do you see anything wrong with the following changes for the collsion LED?

added define for TURN_COL_LED_ON()  and TURN_COL_LED_OFF()   

Code: [Select]

#ifdef ETH_INTERFACE
    #define LAN_REPORT_ACTIVITY                                        // Transmissions/receptions and errors are reported to chosen task (for link LED control, etc)

    #ifdef LAN_REPORT_ACTIVITY
        #define ACTIVITY_LED_OFF()     PTL |= ACTLED;
        #define ACTIVITY_LED_ON()      PTL &= ~ACTLED;
        #define TURN_LINK_LED_ON()     PTL &= ~LNKLED;
        #define SPEED_LED_ON()         PTL = ~SPDLED;
        #define SPEED_LED_OFF()        PTL |= SPDLED;
        #define LINK_DOWN_LEDS()       PTL |= (LNKLED | ACTLED);       \
                                       PTL = ~(COLLED | SPDLED | DUPLED);
        #define TURN_COL_LED_ON()      PTL &= ~COLLED;
        #define TURN_COL_LED_OFF()     PTL |= COLLED;
        #define CONFIGURE_LAN_LEDS()   DDRL |= (LNKLED | ACTLED | COLLED | SPDLED | DUPLED); \
                                       LINK_DOWN_LEDS();
    #endif
#endif
then for the collision interrupt in network_indicator:

Code: [Select]

case ETHERNET_COLLISION:
                TURN_COL_LED_ON();
                uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(COLLISION_TIME), E_TIMEOUT ); // blink collision LED
                ucEvent|=COL_LED_ON;
               
                break;and modified the timer event that turns off the led:

Code: [Select]

case TIMER_EVENT:
            if (E_TIMEOUT == ucInputMessage[ MSG_TIMER_EVENT ]) {
                if(ucEvent & (TX_LED_OFF | RX_LED_OFF))
                {
                    ACTIVITY_LED_OFF();
                    ucEvent &= ~(TX_LED_OFF | RX_LED_OFF);
                }
               
                if (ucEvent & COL_LED_ON)
                {
                    TURN_COL_LED_OFF();
                    ucEvent &= ~(COL_LED_ON);
                }
            }
            break;

24

µTasker general / Re: My setup of CW compiler doesnt like the joining of two lines of "#define"

« on: May 06, 2008, 08:20:00 AM »

Ive now tested this in a second project and it seems ok. Not sure what i was doing that caused the error the first time.

25

µTasker general / Re: about the udp use!

« on: May 06, 2008, 03:25:10 AM »

can you clarify for me what fnReleaseUDP_socket does please?
What actually gets freed - it looks like the socket handle is left alone?

26

Freescale^TM MC9S12NE64 / Re: Activity LED timing

« on: May 02, 2008, 06:59:32 AM »

Ive changed that over to uTasker controlled LEDs now and the activity LED is fine but i can't find any mention of uTasker manipulating the DUPLED (Duplex LED). At the moment with auto negotion enabled the DUPLED is extinguished, but when i was using hardware LED control it is lit.

If uTasker is currently ignoring this LED, is there a way to pick up the current duplex type and manipulate the LED accordingly? I'm expecting the LED to be lit for Full and extinguished for half.

John Dowdell

27

Freescale^TM MC9S12NE64 / Activity LED timing

« on: April 28, 2008, 09:48:01 AM »

I'm letting the hardware do the activity (and other network) LEDs. Do you know a way of making the activity LED stay on for longer in this mode? I have used utasker to do the LEDs before and i see to remember the activity LED staying on for longer than it is in the hardware controlled mode. At the moment it blinks so fast you can hardly see it.
When uTasker is controlling the activity LED, can i control how long the "blink" lasts for?

28

µTasker general / Will a TCP session disconnect as soon as it detects physical link lost?

« on: April 28, 2008, 09:42:15 AM »

does pulling the cat 5 cable out of a utasker project prompt a utasker TCP session to disconnect? I'd like to make this happen if it is not the case. What should i poll to see if link is still there?

29

µTasker general / Is it OK to add items to NETWORK_PARAMETERS struct?

« on: April 23, 2008, 09:41:50 AM »

ive added a few bits and pieces to struct PARS which hasn't caused me any problems yet. I wondered if there would be a problem memory wise with adding anything to NETWORK_PARAMETERS struct

i was playing with adding a multicast ip to the ip filter and thought the struct would be the most likely place to save it.

Code: [Select]

typedef struct stNETWORK_PARAMETERS
{
    unsigned short usNetworkOptions;                                     // Options passed to the network device on configuration
    unsigned char  ucOurMAC[MAC_LENGTH];                                 // when no other value can be read from parameters this will be used
    unsigned char  ucOurIP[IPV4_LENGTH];                                 // our default IP address
    unsigned char  ucNetMask[IPV4_LENGTH];                               // Our default network mask
    unsigned char  ucDefGW[IPV4_LENGTH];                                 // Our default gateway
    unsigned char  ucDNS_server[IPV4_LENGTH];                            // Our default DNS server
    unsigned char  ucOurMulticastIP[IPV4_LENGTH];                        // our default MulticastIP
} NETWORK_PARAMETERS;


30

µTasker general / Re: Relationship between TCP_EVENT_REGENERATE, APP_ACCEPT and APP_SENT_DATA

« on: April 11, 2008, 11:27:34 AM »

thanks,
i guessed that would be the case. No problems.

John Dowdell