Problems Downloading and Debugging uTasker within Rowley Crossworks

[mhoneywill]

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

[mark]

Hi Martin

1) Are you setting the correct target? THUMB FLASH DEBUG or THUMB FLASH RELEASE? [rather than Bare-Minimum Boot Loader?]
You can also download to RAM using the THUMB RAM DEBUG target.

2) It is true that one has be be quite careful with Rowley since it will often replaces the .ld file  - which will compile and load normally but not be able to run. This happens sometimes when something is modified in the project - so be a little careful.

Make sure that uTaskerLM3Sxxxx.ld is being used by checking its properties -> selecting configuration common: verify that it is not being excluded from the build and that its file type is set to "Linker Script".

There is no assembler file used in the GCC project - the start-up should be coordinated by reset_vect[] in lm3sxxxx.c.

I didn't find any thing noticeable in the original part of the project you sent but it looks as though the V13a is missing the .ld and has some assembler code in the system files folder. I think that it is also missing the pre-processor C defines _LM3SXXXX;_GNU

Regards

Mark

[mhoneywill]

Hi Mark,

Thanks for the quick reply  , 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

[mhoneywill]

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

[mark]

Hi Martin

Concerning the entry symbol reset_handler:

This is defined in the Linker options - setting "Entry Point".

It should be _main. This then matches with the reset vector setting in LM3Sxxxx.c

#define START_CODE _main

const RESET_VECTOR reset_vect
#endif
= {
    (void *)(START_OF_SRAM + SIZE_OF_RAM),                               // stack pointer to top of RAM
    START_CODE
};


The project was tested with Rowley V1.7 Build 12 - both for stand-alone image and for firmware upload using the boot loader. I also don't remember hearing of any real difficulties with building from the project version as released (apart from the .ld sometimes getting thrown out after a change in settings).

Perhaps it has something to do with the Build 16 (?)

I will have a go with the latest SP to see whether I have any difficulties and try to get an upgrade to Build 16.

Regards

Mark

[mhoneywill]

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

[mark]

Hi Martin

Yes, I meant the uTasker boot loader.

It is strange that the binaries which are created do run when loading with LM Flash Programmer but not when loading from Rowley. This does suggest that the code is correct but Rowley has a problem with loading it - although a binary file shouldn't be be interpreted in any way, and so I can't understand how this can happen.

Can you then debug the code once loaded? You can set the project up to not download automatically, but just debug the code that is already in FLASH.

I dug out some old notes about working with Rowley and noticed that I did most work with the JLink debugger and the Luminary parts. The reason was that I couldn't get the CrossConnect or the Luminary debug modules to work correctly with it. At the time, I assumed a problem with the Rowley installation on my PC. In comparison, other targets (like SAM7X) worked really well with all debuggers.

Therefore it may be that Rowley doesn't like the uTasker binary - although I still can't imagine why, and also why it was just about possible to work with the JLink (I think that I just couldn't reset and had to reconnect each time to re-start debugging) but the Rowley JTAG debugger gave errors when I tried to do anything. The fact is however that I haven't actually needed to do any debugging on the target for several months and the memory fades a little. Also I tend to switch around between Rowley, IAR and Keil when doing driver development, keeping away from the Luminary inbuilt JTAG since it is rather slow - not to download with - this is great, just to step code with, in which case the Keil U-Link is generally the most comfortable.

The conclusion is that I think that I will need to get in contact with Rowley, get up to date with the Build 16 and see whether it is possible to find out what binary content could be causing Rowley to not want to work properly.

Regards

Mark

[mhoneywill]

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

[mhoneywill]

After some lengthly off list discussions between myself Mark and Rowley these issues have now been resolved, for the benefit of other readers I'll explain the problems below and the solutions we found. I've also attached a  corrected Rowley project file to this post for the main uTasker project. Once I've tested it I'll also post one for the bare minimum bootloader. Just ensure that you are using the lastest SP3 of the utasker project and replace the project file with the one contained in this post.

It should also be noted that my problems related to the downloading and debugging of files within the Rowley IDE. The Binary files produced by Rowley have always been correct and have not changed.

NOTE if you are reading this and there is a later SP avaliable for the Luminary Micros then these fixes will have already been incorporated into the project files by Mark. DO NOT USE THE ATTACHED PROJECT FILES as they may be out of date.

ALso you will need to upgrade your Version of Rowley Crossworks to at least V1.7build17 as a bug was found in the Rowley debugger.

Right here are the problems and the fixes.

1. Firmware would not Download to Target from within Crosworks
The problem was that the firmware loader was missing from the project file, so Rowley didn't know how to download to target flash. In the project properties for each target configuration the target option "Loader File Path" needed to be set to "$(StudioDir)/targets/Luminary_LM3S/Release/Loader.elf"

2. Target would not Reset correctly
The problem was that Rowley had no reset script defined. In the project properties for each target configuration the target option "Reset Script" needed to be set to "RAMReset()" for RAM builds and "FLASHReset()" for FLASH builds.

3. Could not set Breakpoints in the Debugger
The problem was that the Rowley debugging system could not handle there being no start-up assembler code. There was a cludgy code fix but the easiest solution is to upgrade Crossworks to version 1.7build17 or greater.

3. Setting a breakpoint on startup
Not a major thing but to get the code to pause on startup for Debug builds, you need to go to "Tools > Options > Debugging > Breakpoint options" and change the initial beakpoint setting to _main 

I hope this helps other readers, and thanks again to Mark for some fantastic support.

Cheers

Martin Honeywill