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

Pages: 1 ... 9 10 [11] 12
151
Thanks Mark for that comprehensive reply,

Downloading build 16 from Rowley is very easy its available from their web site.

If you have a Rowley Crossconnect debugger (Classic style in the grey box) then you need to ensure its upgraded to V2.9 firmware to allow it to work with M3 cores. This upgrade is on their website.

I'm sure its a project configuration problem as I can happily use Rowley to download and debug other projects, specifically the Luminary Micro samples which Rowley supply a port for. This works with both JTAG programmers I have here, either the built in Luminary one or a Rowley Crossconnect.

With your project as supplied Rowley cannot download the produced binary, I suspect because the wrong Rowley loader is being used or it has the wrong parameters.

You asked if I could debug code once it is loaded, I can't. This maybe because Rowley tries to run to main but you don't have a main but do have a _main. In the first version of the project I sent you I had tried to create a new project and had used the Rowley startup code, I needed to rename _main to main to allow the program to halt at this point.

Because I was using the Rowley startup code and not your .ld file I think all the interupt vectors would have been defaulted and possibly also in flash.

Maybe it a combination of the wrong loader being selected in the project file and an incompatibility between your .ld files and the system that Rowley uses. I'ts just an area I'm not familiar with.

I would appreciate it if you were able to talk to Rowley to resolve this problem. 

Cheers

Martin


152
Hi Mark,

Wow you were up late, making the change to the linker option - "entry point" now allows the link to work :-) in my new project uTaster13a. The download works but the code does not run (the status light is not flashing).

Just to check you say that uTasker has been tested for "both for stand-alone image and for firmware upload using the boot loader". When you say boot loader do you mean the uTasker bootloader?

Just to be clear what I am trying to to is build uTasker in Rowley, and to download this image within Rowley using the "Build and Debug" or "Build and Run" menu options. I also want to interactively debug in Rowley by setting breakpoints etc.

Both my project "utasker13a" and your project produce bin files that can be downloaded via the Luminary Micro Flash programmer and Run (well I can ping them and the status light flashes).

I hope this makes my problem a bit clearer.

Martin

153
HI Mark,

After examining my project file an your original I noticed the following lines in my project that were not in yours

    <configuration Name="Flash" Placement="Flash" arm_target_flash_loader_file_path="$(StudioDir)/targets/Luminary_LM3S/Release/Loader.elf" linker_section_placement_file="$(StudioDir)/targets/Luminary_LM3S/flash_placement.xml" target_reset_script="FLASHReset()"/>
    <configuration Name="RAM" Placement="RAM" linker_section_placement_file="$(StudioDir)/targets/Luminary_LM3S/ram_placement.xml" target_reset_script="RAMReset()"/>

Adding these lines seemed to make the Flash download now work, so it looks like by default the wrong loader is being called, maybe this is because I have support for the NXP LPC chips loaded as well in crossworks, but then I guess you do too. I know some of the above settings are not correct as the RAM download does not work.

Well I'm making slow progress.

Martin

154
Hi Mark,

Thanks for the quick reply  :D, in answer to your questions.

1) Yes I've tried all three of the targets you suggested.
2) The .ld files I have are the same as those supplied in Beta 1, so Rowley has not replaced them

3) The uTaskerLM3Sxxxx.ld is not being excluded from the build as far as I can tell(I can't see an option to exclude it by right clicking on the file). How do I know if Rowley is using it I wonder?

4) The project I sent you "utasker13a" does include the preprocessor defines _LM3SXXXX;_GNU I put them in the common section as they apply to any build.

5) I know the .ld files were not included in my build, I was trying to see if a Rowley style build would work. Not really sure how the .ld files work

6) I added the .ld file you suggested to my project and removed the rowley startup code files. Now when I do a build I get the following message

c:/program files/rowley associates limited/crossworks for arm 1.7/gcc/bin/ld: warning: cannot find entry symbol reset_handler; defaulting to 00000008
Build failed

So I'm not much further on :-(

I've just tried again with the and Rowley tries to download to the target which completes, it then tries to verify the target and this fails.

Does your build just work in Rowley, can you download in Rowley via JTAG? when you do a debug build does Rowley start up and run to main?

Cheers

Martin

155
Hi Mark,

After getting the uTasker working correctly in a simulated environment I have turned my sights to getting uTasker working on real hardware.

I'm using an LM3S6965revc development board from Luminary Micro. I'm also using Rowley Crossworks V1.7 build 16.

I can compile the software and produce a bin file which I can then download to the target board using the Luminary Jtag flash programming software, this works fine.

The problem comes when I try to compile and debug uTasker within the Crossworks environment, I get a number of problems that makes me think there are problems with the uTasker13.hzp project file.

As a reference I'm also compiling the LWIP web server application from the from the luminary micro driver library, this proves my Rowley install is working and that JTAG downloading from the rowley IDE works.

I'm using Rowley with both their Crossconnect JTAG programmer (upgraded to the latest firmware) and the Luminary Micro Built in JTAG programmer, and I get the same problems using either.

My problems are

1. If I "Build and Run", or "Build and Debug" the uTasker project, I cannot even get Rowley to download the file without verification errors. I suspect that the Rowley may be using the wrong loader file.

2. If I use the Rowley memory usage display CTRL ALT Z then it gives me no indication of the SRAM used, again this makes me think the project file is not setup correctly.

Have you tried debugging within the Rowley environment? with your supplied project file?

In an effort to get to the bottom of the above problems I created a new project and did the following things.
1. Added all the files to it,
2. Set the two defines _LM3SXXXX and _GNU in the common project properties
3. Added ..\..\..\Applications\uTaskerV1.3. to the common user include directories
4. Set optimisation to "optimise for size"
5. As this new build was using the Rowley start-up code I added a define  "#define _main main" in line 55 of LM3Sxxxx.c. The Rowley start-up code looks for "main".

The above now compiles and downloads correctly via either JTAG adapter, which is an improvement, this seems to imply that there is a problem with the target setup of the supplied project file.

Although the code downloads it does not run correctly, I suspect because of a problem with the interrupt vectors or the fact that Rowley start-up code is being used and probably no reference is being made to the uTaskerLM3SXXXX.ld file. I'm still not sure how the low level side of uTasker works but I'll try and investigate further.

I've attached a copy of my project file to this post.

I'd appreciate your thoughts on the above.

Cheers

Martin

156
Thanks for the quick reply Mark,

But I did check and I had no resource.h file in \applications\uTaskerV1.3 to delete

But I did find that I had a resource.h file in applications\utaskerV1.3\Simulator that seemed to be old, I've deleted this file and the project now compiles correctly in VS2008

Cheers

Martin



157
Hi Mark,

These are my experiences of getting the simulator working with SP3

My experience loading uTasker SP3 on an LM3S6965 demo board.
 
I'm using Rowley Crossworks V1.7 build 16 as my arm compiler
and Visual Studio 2008 SP1 as my windows compiler.
 
This is the sequence I followed.
 
1. I did a clean install of the uTasker LM3Sxxxx beta software
 
2. I then applied SP1, SP2 and SP3 in order
 
3. I made the changes detailed in the forum relating to SP3
 
4. I renamed config_sp3.h to config.h
 
5. I undefined SPI_FILE_SYSTEM in config.h (I was not using that)
 
6. I selected EK_LM3S6965 as the target device
 
7. I opened uTaskerV1-3.dsp is VS2008 wheich converted the project into a VS2008 project
 
8. Next I tried to compile the simulator, It failed to compile with the following error
   Error   1   error RC2104 : undefined keyword or key name: ID_WIRESHARK_REPLAYLASTFILE   
   The only way I could get it to compile was to make the following changes to the uTasker.rc file

    POPUP "&Wireshark"
    BEGIN
//        MENUITEM "&Replay last file",           ID_WIRESHARK_REPLAYLASTFILE
        MENUITEM "&Load Wireshark/Ethereal file to play back", ID_ETHEREAL
    END
    POPUP "&LAN"
    BEGIN
        MENUITEM "Select working &NIC",         ID_LAN_NIC
    END
    POPUP "US&B"
    BEGIN
        MENUITEM "&Enumeration",                ID_TEST_ENUMERATION
//        MENUITEM "&Disconnect",                 ID_USB_DISCONNECT
//        MENUITEM "Attach &low speed device",    ID_USB_CONNECTLOWSPEEDDEVICE
//        MENUITEM "Attach &full speed device",   ID_USB_CONNECTFULLSPEEDDEVICE

    END
    POPUP "&Port Sim"
    BEGIN
//        MENUITEM "&Repeat last script",         ID_PORTSIM_REPEATLASTSCRIPT
        MENUITEM "&Open Script",                ID_PORTSIMULATOR_OPENSCRIPT
    END

10. The project is now working in the simulator

Any ideas why I had to change the uTasker.rc file

Cheers

Martin

158
NXPTM M522XX, KINETIS and i.MX RT / Re: Dot-matrix LCD: interface and GUI
« on: December 02, 2008, 10:55:51 AM »
Which Driver chip are you using? I have generic C code for a Toshiba T6963 if that is any help

Cheers

Martin Honeywill

159
Luminary Micro TM LM3SXXXX / Re: Using the UART in the simulator.
« on: September 21, 2008, 04:58:35 AM »
I've not tried them with the uTasker simulator but you might want to try these free virtual comm port simulators that create pairs of virtual comm ports on your PC that are connected together by a virtual null modem cable. You could connect UTasker to one port and a terminal emulator to another.

See

http://www.mixw.net/index.php?j=related
http://com0com.sourceforge.net/
http://developer.berlios.de/projects/n8vbvcomdriver/
http://www.hw-group.com/products/hw_vsp/index_en.html

Hope these help

Cheers

Martin

160
µTasker general / Re: uTasker and Vista
« on: May 30, 2008, 06:42:05 PM »
Hi Mark,

I'm running XP with VisualStudio2008 professional edition. For my testing I am using the Microsoft LOOPBACK adapter.

Just compiled utasker1.3 SP1 for LM3Sxxx and ping worked fine mostly <1ms replys. "Arp -a" and "arp -d" also seemed to work as expected.

Maybe its a Vista Thing, I'll try compiling to a standalone exe and run it on a vista machine.

Cheers

Martin Honeywill


161
µTasker general / Re: Porting UTasker to the Rabbit Processor
« on: May 22, 2008, 12:03:51 PM »
Hi Mark,

Where should I send the module? I couldn't find an address on your web site.

Shall I keep the discussions about progress etc in this forum post? Might be useful for other users to see my trials and tribulations.

I will take your suggestion and try an look at the simulator first, these are the procedures that I think I should follow.

1. Turn off Ethernet using, #define DEVICE_WITHOUT_ETHERNET this should remove a chunk of code.

2. Define the end of the Heap, I presume __heap_end__ is a compiler/linker variable that contains this value. I'll see what Softools has.

3. Rename LPC23xx.c etc. to R3000.c (for the rabbit 3000) I presume I need to work my way through this file producing rabbit versions of all the functions. Starting with IO functions. Do you have a minimal version of this file that you use for initial development?

4. The Softools setup, contains drivers for the Ethernet, and Serial Ports, also flash programming is also supported (but it does inhibit interupts)  so I think these could be used rather then re-inventing the wheel.

5. Softools has a Tick Timer so I could hook into this for the tasker. Where should I look in the code to set this up? What Tick time base do you normally use

6. Ethernet, Serial and Flash will follow later.

It would also be nice to create a Debug output channel that will act as a debug printf output, in the simulator it will route to a  text box that can just stream output. On the target this would either route nowhere or in the case of the Softools compiler, route to a printf terminal interface that it supports whist in debug mode. This concept would be easy to extend to other targets that supported some form of simple debug channel.

Cheers

Martin


162
µTasker general / Re: Porting UTasker to the Rabbit Processor
« on: May 21, 2008, 10:30:26 PM »
Hi Mark,

Well in for a penny in for a pound, I'll give it a shot I think. I'll have to do it in my own time at least initially. (read evenings and not work time). And I might need a bit of hand holding  ;-).

The rabbit does have a massive following and I think that is basically down to its Ethernet support. If you use the softools compiler that I mentioned then you get away from the reliance on the tools it comes with. And yes Dynamic C can drive you mad.

If you want I can ship you an eval board with a Rabbit RCM3200 module, the demo version of the softools compiler available from their website will compile to RAM, it just will not program the Flash. This is fine for development as you debug in ram anyway.

Cheers

Martin

163
µTasker general / Re: Porting UTasker to the Rabbit Processor
« on: May 21, 2008, 05:26:49 PM »
Hi Mark,

Thanks for your quick response, you ask what are the advantages of the Rabbit Processors.

Well the simple answer is for a new product NONE in my opinion.

For a slightly longer answer, we currently have products that use the Rabbit processor, so it would be nice to have a unified environment across processors. Also the Rabbit processors are available in Core modules which allow users to have a fast time to market for products. You can get a TCP IP stack for this processor but it is quite bloated and is based around the Dynamic C compiler that the chip supplier produces. This is a NON ANSI C compliant complier that is quite buggy. The TCP IP stack has been ported to Softools by Softools but it doesn't have all the bells and whistles that uTasker has, also it will not run in the simulator.

I admit that this may be more of an academic exercise that anything but, it might give you another market for uTasker. !000's of rabbit modules are sold and the yahoo groups for Rabbit and Softools are quite active with users. If nothing else it might raise the profile of uTasker if it is known that there is another Stack option available for it. I can see a number of current Rabbit users migrating to Chips like the LPC23xx and the Luminary parts, and giving them an upgrade path could be interesting. The one advantage of the rabbit modules 4 or 5 years ago was that they provided a quick and easy way to add TCP IP connectivity, and they came with loads of software examples.

I also think your concept of a Simulator is a very powerful one and is something that would appeal to Rabbit users. Especially as new peripherals could be added and simulated, like Graphics LCD displays and Keypads etc. I think the whole methodology of writing a program from the ground up that will run in both the simulator and  the target device introduces practices that make the resulting code inherently more portable. i.e. storing all hardware specific code in separate modules.

One thing I would do also is to simplify some of the uTasker examples, rather that have one huge application.c file with loads of #ifDefs I would have lots of little examples that showed one aspect of uTasker. Like a UDP example or a simple single page WEB server, with no file system. This is what was so appealing about the Rabbit, you had a simple example of say a WEB server and it was easy to understand what was happening.

Below is an example of their Static Web Page Demo

Code: [Select]
/*******************************************************************************
        static.c
        Z-World, 2000

        A very basic example using the HTTP library. This program
        completely intilizes the library, outputing a basic static
        web page.
*******************************************************************************/


/***********************************
 * Configuration                   *
 * -------------                   *
 * All fields in this section must *
 * be altered to match your local  *
 * network settings.               *
 ***********************************/

/*
 *  The TIMEZONE compiler setting gives the number of hours from
 *  local time to Greenwich Mean Time (GMT).  For pacific standard
 *  time this is -8.  Note:  for the time to be correct it must be set
 *  with tm_rd which is documented in the Dynamic C user manual.
 *
 */

const int TIMEZONE = -8;

/********************************
 * End of configuration section *
 ********************************/

#include "stcpip.h"

/*
 *  #pragma init_file is a WinIDE SC2000 feature that takes the binary image
 *  of a file, places it in extended memory on the controller, and
 *  associates a symbol with the physical address on the controller of
 *  the image.
 *
 */

extern char const far index_html[];
#pragma init_file( index_html, "pages/static.html" )
extern const char far rabbit1_gif[];
#pragma init_file( rabbit1_gif, "pages/rabbit1.gif" )

const char MAX_TCP_SOCKET_BUFFERS = 1;

/*
 *  http_types gives the HTTP server hints about handling incoming
 *  requests.  The server compares the extension of the incoming
 *  request with the http_types list and returns the second field
 *  as the Content-Type field.  The third field defines a custom
 *  function to handle that mime type.
 *
 *  You can get a list of mime types from Netscape's browser in:
 *
 *  Edit->Preferences->Navigator->Applications
 *
 */

/* the default mime type for '/' must be first */
SSPEC_MIMETABLE_START
SSPEC_MIME( ".html", "text/html" ),
SSPEC_MIME( ".gif", "image/gif" ),
SSPEC_MIMETABLE_END

/*
 *  http_flashspec assocates the file image we brought in with ximport
 *  and associates it with its name on the webserver.  In this example
 *  the file "samples/http/pages/static.html" will be sent to the
 *  client when they request either "http://yoururl.com/" or
 *  "http://yoururl.com/index.html"
 *
 */

SSPEC_RESOURCETABLE_START
SSPEC_RESOURCE_XMEMFILE( "/", index_html ),
SSPEC_RESOURCE_XMEMFILE( "/index.shtml", index_html ),
SSPEC_RESOURCE_XMEMFILE( "/rabbit1.gif", rabbit1_gif ),
SSPEC_RESOURCETABLE_END

void main()
{
    longword _IP;
char buffer[ 20 ];

WDT_DISABLE();
if( xavail() < 0x10000UL )
{
printf( "This demo requires 256k or more of RAM" );
return;
}
startTimer( 100, 0, 1 ); // Timer must be at IP=1
ipset0();

/*
*  sock_init initializes the TCP/IP stack.
*  http_init initializes the web server.
*/

// Select ethernet hardware: usingAsix, usingDevKit, usingRealtek, usingSMSC
usingAll();
sock_init();
http_init();

// Wait for DHCP server to send an IP address.
// ifconfig( IF_ETH0, IFS_DHCP, 1, IFS_UP, IFS_END );
if( ifconfig(IF_ETH0, IFS_DOWN, IFS_IPADDR, aton("192.168.18.1"), IFS_NETMASK, aton("255.255.255.0"), IFS_UP, IFS_END) ) printf("ifconfig failed!\n");
while( ifpending(IF_ETH0) == IF_COMING_UP )
tcp_tick(NULL);
ifconfig( IF_ETH0, IFG_IPADDR, &_IP, IFS_END );
    printf("My IP address: %s.\n", inet_ntoa( buffer, _IP));

/*
*  tcp_reserveport causes the web server to ignore requests when there
*  isn't an available socket (HTTP_MAXSERVERS are all serving index_html
*  or rabbit1.gif).  This saves some memory, but can cause the client
*  delays when retrieving pages.
*/

tcp_reserveport(80);

/*
*  http_handler needs to be called to handle the active http servers.
*/

while (1) {
http_handler();
   }
}

I hope this explains my thoughts.

Cheers

Martin

164
µTasker general / Porting UTasker to the Rabbit Processor
« on: May 21, 2008, 02:10:13 PM »
Hi Mark,

Partly in an exercise to understand utasker in more depth I would like to look at the possibility of Porting uTasker to the Rabbit Processor. Specifically the Rabbit 3000 processor on the RCM3200 board, which uses an ASIX chip for Ethernet access.

We currently use these RCM3200 modules in some of our products, see www.rabbitsemiconductor.com

We use the Softools C compiler www.softools.com which is an ANSI C compiler so that part should be OK. Much better that the Dynamic C compiler supplied by Rabbit / DIGI.

The Rabbit is basically an 8bit device which uses paged memory to access up to 1M of memory. The RCM3200 module has 512K Flash and 512K Ram. The fact that the rabbit is limited to 64K memory, without paging and that uTasker supports small memory sizes looks like it might be a good fit.

My first question is do you mind if I have a play with this, I am currently evaluating the LPC23xx and LM3Sxxxx versions of uTasker and have merged the two stacks. Would one of these make a good basis to start from or would you look at something like the N64 version as a starting point, I presume the stacks are the same and just the hardware specific files are different.

Cheers

Martin Honeywill

165
µTasker general / Re: Creating a new Task
« on: April 06, 2008, 11:39:09 AM »
Hi Mark,

I think this is an excellent idea to consolidate all the various bits of help and documentation into one online resource, it would be good to allow this resource to also be available off line too.

We use a product called Help and Manual from ec-software http://www.ec-software.com/index.html this allows us to have one single source for PDF manuals windows CHM files and online HTML files. Its not the cheapest product out there but it is very good. Just thought I'd let you know about this product in case you hadn't come across it.

Cheers

Martin

Pages: 1 ... 9 10 [11] 12