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

Pages: [1]
1
NXPTM M522XX, KINETIS and i.MX RT / Re: Tasks & Switching from Sim to Target
« on: May 10, 2011, 07:24:56 PM »
OUCH! 

In the make file, the line
INC = -I../../uTaskerV1.4
causes the GCC build to find uTaskerV1.4\TaskConfig.h  not the one in the current application directory and therefore not the same one that Visual C finds during the simulator build.  This explains why the GNU build wasn't barking at me when I didn't include the source files for my task in the make file...it also wasn't building the TaskConfig.h file that referred to the task, so there were no undefined references during the GNU build.  And during the simulator build, Visual C was finding the proper copies, building my source files, and happy as a clam.  Changing the behavior of the demo C files in my application directory still changed the behavior of the program as expected, so there weren't many other clues that it was finding the wrong .h files.

Changing the line to
INC = -I../
seems to fix everything.

Using
#if defined(_GNU)
#error "build was here"
#endif
finally illuminated the problem.

John

2
NXPTM M522XX, KINETIS and i.MX RT / Re: Tasks & Switching from Sim to Target
« on: May 10, 2011, 04:30:31 PM »
Since the debug terminal is working, I can go to stats and show memory use.  It says
"Free heap = 0x0ba4 from 0x5400"
"Unused stack = 0x16df"

Isn't this saying that I'm probably okay on memory? 

John

3
NXPTM M522XX, KINETIS and i.MX RT / Tasks & Switching from Sim to Target
« on: May 10, 2011, 03:58:22 PM »
More problems switching from the simulator to the 52233DEMO target...

I figured out that while the Visual C environment adds new files to the build, the Makefile used for GCC is NOT updated, so my tasks weren't getting compiled in.  (Funny, no linker errors that I could see).  Fixed that, and can see my task functions in the map file. 

Still, I can't get a simple task that prints a debug message to the serial port to work.  The original demo's debugging messages make it there just fine.  My task starts up fine and also prints to the serial port when running under the simulator. 

I'm sure it's something stupid, but would appreciate any pointers, please.

Task just calls fnDebugMsg("Init is running.\r\n"); and returns.
config is "MEDIUM_QUE", (DELAY_LIMIT) ((5*SEC) + (PHY_POWERUP_DELAY)), 0, UTASKER_STOP

John

4
NXPTM M522XX, KINETIS and i.MX RT / //#define USE_SMTP breaks buffered TCP client?
« on: April 21, 2011, 07:43:25 PM »
This may be a silly question, but is there a valid reason why USE_SMTP must be defined to use buffered TCP?

Running under the simulator, configured for 52233DEMO...

My uTasker TCP client connects fine with it defined, but with it commented out, the client never sends any packets to connect to the server (based on WireShark).  HTTP and FTP can be commented out without any problems. 

I thought it might be a problem with the parameters file, so I renamed Simulator\FLASH_M5223X.ini, fixed some of the defaults, and still it wouldn't talk.  Uncommented USE_SMTP and rebuilt and it works again. 

JPA

5
µTasker general / Re: TCP client send
« on: April 20, 2011, 03:54:42 PM »
Never mind.  I re-read the later posts (in the TCP thread) about buffered TCP, and seem to be making progress.

JPA

6
µTasker general / TCP client send
« on: April 19, 2011, 10:55:57 PM »
(Should I be adding to the pinned TCP topic?)

I'm trying to create a TCP client and send data.  I can connect, and the first packet gets through, but then the second packet is tagged as "TCP Out-of-Order" by Wireshark and is apparently not received by the server.  The basic intention is to make what is essentially a serial-to-ethernet converter.  The serial receive routines gather together a whole message and call "as_send" below.  It is NOT called from the callback function since it's not being sent as the response to a server message.  Is that the key?  The callback function is the fnTestListener from your TCP thread except the TCP_EVENT_DATA case just prints out the fact that data has been received (so then it falls through and returns APP_ACCEPT).

I've attached the Wireshark log... uTasker client is 192.168.1.10 trying to send a 32 byte packet to 192.168.1.4.

JPA

Code: [Select]
typedef struct stTCP_MESSAGE
{
    TCP_HEADER     tTCP_Header;     // reserve header space
    PACKET_TYPE   packet;
} TCP_MESSAGE;

//=============================================================================
int as_send(int as_index, const void *msg, size_t len, int flags)
{
unsigned int i;
TCP_MESSAGE test_message;

uMemcpy(&test_message.packet, msg, sizeof(PACKET_TYPE));
if (fnSendTCP(test_client_socket, (unsigned char *) &test_message.tTCP_Header, sizeof(PACKET_TYPE), TCP_FLAG_PUSH) > 0) {
fnDebugMsg("sent ok?\r\n");
        return 0;
}
else
return 0;
}

7
NXPTM M522XX, KINETIS and i.MX RT / Re: Sourcery and M52233DEMO
« on: April 10, 2011, 09:45:48 PM »
Mark,

My mistake...apparently the USB BDM on the board must be completely unplugged after programming with CFFlasher.  Reset and even the On/Off switch didn't do it.  When the board suddenly started working later (and the serial port was spitting out messages about an SDCard timeout) I mistakenly assumed the two were connected. 

GCC build is up and running.

John

8
NXPTM M522XX, KINETIS and i.MX RT / Sourcery and M52233DEMO
« on: April 08, 2011, 09:36:52 PM »
Are there linker scripts available somewhere for Sourcery G++ and the M52233DEMO board?

Anything else that needs to be done to get it running?  Flashed the pre-built image in and everything's great.  Simulation is great.  GCC build...not so much. 

Got the code to compile and link, flashed it...nothing.  Suddenly sometime later it seems to have sprung to life after something timed out. 

John

9
NXPTM M522XX, KINETIS and i.MX RT / Re: win7 + vc2010 simulator dies when writing to flash
« on: April 08, 2011, 04:04:13 PM »
For what it's worth, I got the same results (both the problem and the working solution) under similar conditions, Win7, VC2010.

An earlier test with WinXP and VC2010 didn't have this problem but had other problems with an apparently old version of FTP  ;) that I worked around by sending the files one by one. 

John


Pages: [1]