µTasker Forum

µTasker Forum => STTM STM32 and STR91XF => Topic started by: guibiao on September 30, 2009, 12:50:23 AM

Title: RIDE7
Post by: guibiao on September 30, 2009, 12:50:23 AM
Hi, Mark. Did you ever try to use RIDE7 to compile the STR91XF project? I cannot seem to enable the system tick INT with RIDE7. Thanks!

Guibiao
Title: Re: RIDE7
Post by: mark on September 30, 2009, 10:59:42 AM
Hi Guibiao

This is a timely question since I have just last week made configurations for RIDE 7.
A long time ago I did try it too (maybe it was called RIDE 4 or something then) but can't remember whether it was successful or not.

The fact is that RIDE7 uses GCC as compiler and I did have to make some changes to get the project to work with GCC; the RIDE 7 IDE has little to do with this. RIDE7 is however useful (especially RFlasher 7) in that it can be used to configure the internal FLASH (which other IDE's often can't do) and so ST CAPS is no longer needed when working with a boot loader in Bank 1 [CAPS doesn't work under Vista so this solves that one...].

I will send you my changes by email so that you can verify them.

Expect sometime in the not too distant future a V1.4 release for ST including RIDE 7, uVision, IAR, Rowley, stand-along GCC; with uGLCDLIB and MODBUS. [Due to the fact that the STR91 project is not very popular, support was going to be dropped - but there has been a slight increase in interest this summer which has led to the decision to give it one last polish-up effort so that it is completely up to date with all-round support for standard environments. If this still doesn't catch on it will then be shelved - but no one can accuse me of not making that last effort... We'll see how it goes ;-)

Regards

Mark
Title: Re: RIDE7
Post by: Sacha_D on September 02, 2010, 01:34:28 PM
I filled form and got uTasker for STR912. I tried to build it with RIDE7 (i need .hex file for JTAG programmer by ST Microelectronics), but Ride7 don't understand assembler syntax, such as ";", "EQU" and others. It can't find TICK_RESOLUTION. When I tried to load into microcontroller uTaskerV1.3.obj from uTaskerV1.3.0_STR91XF\Applications\uTaskerV1.3\CAPS_STR91XF, program was loaded successfully, but I can't find it on 192.168.0.3 net mask 255.255.254.0. Ping outputs: unreachable host, even my computer has address 192.168.0.2 and same net mask. How to build and to run uTasker? I'm a beginner here. Thank you.
Title: Re: RIDE7
Post by: mark on September 02, 2010, 03:54:25 PM
Hi

#define TICK_RESOLUTION      50
This is in config.h.

V1.3 doesn't have a RIDE project (GCC based) so you may need to do some work to get this operating.
If you load a pre-compiled file it may depend on the HW that it is running on whether the Ethernet works (which HW do you have?)

Check also the SW demo page: http://www.utasker.com/SW_Demos.html since it may have a target that you can test with.

Regards

Mark
Title: Re: RIDE7
Post by: Sacha_D on September 03, 2010, 07:00:31 AM
I tried to use it, but got the same result - host is unreachable. I connected it and my computer into hub, set-up my ip:192.168.0.2 and net mask 255.255.254.0.
Can you create for me .hex file with ip 192.168.5.111, net mask 255.255.255.0, default gateway 192.168.5.2? In example by Adam Dunkels it works.
V1.3 doesn't have a RIDE project (GCC based) so you may need to do some work to get this operating.
- What shoud I do?
Title: Re: RIDE7
Post by: mark on September 05, 2010, 12:13:11 AM
Hi

Please could you tell me which hardware you are running?

I have the following that I can verify on:
STR9_DONGLE
REva_DAUGHTER
STR912_SK


I can generate a test file for you as soon as I know - if you are using something else you will need to state which PHY it has connected.

The STR912 project is strange. It has very few users (as seen by the posts here) which means that it doesn't often get much attention. In fact I do have a V1.4 version here with RIDE project integrated which works but there hasn't been any incentive to release this. I think that one of the biggest problems is the complexity of the device with its configurable boot FLASH. Originally CAPs was used to configure this and was acceptable but there is no CAPs version that operates with Vista (like it was dropped by ST ?). But it is possible to configure with the newer RIDE version and the Raisonance debugger (CAPs also only really worked with this debugger). Other IDEs (like Rowley or IAR) are great for debugging but don't seem to support configuring the FLASH. Essentially this means that one really needing a Raisonance debugger to configure but RIDE (the Raisonance IDE based on GCC) is not really usable and so further works needs more, and different, tools. All in all quite a messy situation which doesn't really inspire developing for, or with, the chips.

If we can get the binary working correctly on your board (I'll build with RIDE) it may give me that extra incentive to get a V1.4 wrapped up, which will then allow you to work directly with this, rather than need to mess around getting the V1.3 project patched up....;-)

Regards

Mark
Title: Re: RIDE7
Post by: Sacha_D on September 06, 2010, 07:30:09 AM
Hello, my STR912FAW44X6 was placed onto self-created board. PHY is MICREL KSZ8041TL. STR9_DONGLE, REva_DAUGHTER, STR912_SK, as I saw, have STE100P.
How transform uTasker under PHY MICREL KSZ8041TL?  Is it possible? Which files/libs I need?

When i try to ping uTasker Simulator (which was wrote in Visual C++) I get answer: Time interval for waiting request was passed. Which net configuration on my computer shoud I set-up? Windows 7.

I attached captured packets by WireShark, when I pinged Simulator.
Title: Re: RIDE7
Post by: mark on September 06, 2010, 01:55:56 PM
Hi

If you remove the following check from STR91XF.c

    if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) return;

it may allow the Micrel device to operate - usually the PHYs will default to an operational mode. To get also the check  to work, the PHY's ID needs to be adjusted accordingly in app_hw_str91xf.h.

However I don't know whether the board is actually running correctly yet - make sure that the watchdog LED is blinking as it should be (for example). Also you should have a menu on a UART which can be used to monitor the device and change settings.

In the case of the simulator, I see that the ARP broadcast is being responded to correctly. There is however no response to the PING request itself. This may have something to do with IP check sum offloading (see http://www.utasker.com/forum/index.php?topic=180.0) but I would have expected to see this in the recording (?).

I suggest following the Ethernet frame debugging description towards the end of the STR91XF tutorial http://www.utasker.com/docs/STR91XF/uTaskerV1.3-Tutorial-STR91XF.PDF. You will then be able to identify why the PING request is (presumably) being rejected although the ARP broadcast was OK.

Regards

Mark
Title: Re: RIDE7
Post by: Sacha_D on September 07, 2010, 01:10:48 PM
Thank you. Simulator in Visual Studio works very well. it's really great.

What changes shoud I do in project for make it compatible with Ride7?

Can you send me uTasker .hex file with deleted 
if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) return;
for I try to load it into microcontroller?
Title: Re: RIDE7
Post by: mark on September 07, 2010, 11:47:45 PM
Hi

I managed to to a bit of work on this today. I think that it is best that you make any changes (and debug on the target if necessary) rather than me make them. This way you will get to know the project better and then be able to control the solution to suit.

There is a SW update here: http://www.uTasker.com/software/V1.3/Update_RIDE7.zip

This includes a RIDE7 project and updated GCC configuration. Simply copy the content to the same directories as in the zipped file (overwrite the GNU_STR91XF directory completely and add the new RIDE_STR91XF directory). There are only 2 new files for the device - these are Hardware/STR91XF/STR91XF.c and crt0_str91x.s. These have been slightly altered to be compatible with GCC and the old versions can be overwritten.

Both the standalone GCC (chose the GCC build target from VisualStudio and ensure that the GCC binary path is correct in Build_STR91XF.bat) and the RIDE7 project then build without errors or warnings!

If you can successfully build these too then we are almost there.

I didn't have time to test the binary produced and also don't actually expect it to run on the target without a bit of tuning. However you could try loading it and check that you can do some basic debugging on your target. Specifically, stepping through the start-up code.

I will explain more details once you have tried this first step since there are some important things to discuss concerning the FLASH configuration of the chip - some practical tests can then follow to ensure that the configuration is correct (also how to check and correct when needed) and then PYH adjustments so that your board can finally run the project.

Once the V1.3 project is successful using RIDE7 (and standalone GCC) we can move over to a V1.4 version - it has a great many more features that V1.3 (like utFAT to allow SD cards to be used among others).

Tell me when you have completed the first step.

Regards

Mark


Title: Re: RIDE7
Post by: Sacha_D on September 08, 2010, 12:31:52 PM
Hello. I upgraded it to 1.4, commented
Quote
if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) return;
, build, load .hex. into microcontroller.

Result:
Ethernet port has 2 LEDs.  (if see the same, that on picture in MS Visual Studio project) Left - always blinking rapidly, right - always lights.
ping 192.168.0.3
Answer from 192.168.0.2: host is unreachable.

Then I tried change value of TARGET_HW in file config.h to all listed values, such as:DEMO9S12NE64, AT91SAM7X-EK, SAM7X-EX256, ... etc.
Result was the same.
Is the main problem in MICREL KSZ8041TL? What do next?
Title: Re: RIDE7
Post by: mark on September 08, 2010, 12:40:59 PM
Hi

- Can you confirm that you can now build without errors?
- Also, that you can download the binary to the board?
- How do you load the code? Using CAPs or using RFlasher7?

I don't think that the Ethernet port LEDs are helping since they often behave like this when the PHY has not been configured.

- Can you debug the code? That is, connect using the debugger and step the initialisation code?

Presently I don't expect that the code is running (do you have an LED connected to a GPIO of the processor which can be used to verify that the TICK is operating?). However the reason for it not running is very probably the FLASH configuration, which is the next point to be studied.

Regards

Mark

Using other configurations like DEMO9S12NE64 will no not work since the packet that you have is only of the STR91XF.


Title: Re: RIDE7
Post by: Sacha_D on September 08, 2010, 01:23:47 PM
Yes. I build it without errors.
I use Flash Link cable and JTAG Programmer by ST. (I build project in Ride, then load .hex in controller in JTAG Programmer). Flash Link Cable connects to LPT port in my PC.
I don't know how debug program, loaded into microcontoller. In what program/debugger?
Title: Re: RIDE7
Post by: mark on September 08, 2010, 02:25:54 PM
Hi

You should be able to do basic debugging in RIDE7.

If you don't have a full version it is probably limited to small code size - in this case first remove options (like serial interface, Ethernet, etc.) to make a small enough test program and try with that. (These can be commented out in config.h and added again later).

Once this test program  starts correctly a larger program will also start correctly and you may be able to work with just the uTasker simulator as debugger. But first the project needs to be basically functional and it is worth investing a bit of time to understand the details since this knowledge will be useful for solving difficulties in the future.

Here is a check list of what needs to be correct for the project to start. I will then give more details of practical methods to achieve each step with the available tools.

1) The FLASH is the STR91XF must be configured to either boot from bank 0 or bank 1 as required
2) The project needs to be linked to match the FLASH configuration
3) The initialisation code must also match the FLASH configuration and set the FLASH registers accordingly
4) The file system and parameter system must also be correctly configured to respect the FLASH memory layout

As seen from the list it is quite easy for something to not match and this usually results in the board not being able to start. To achieve the correct configuration requires a bit of knowledge of the chip and the compiler tools. It also requires the correct HW tools and programs, whereby not all available programs seem capable of everything.

This means that the chip is certainly not the simplest to use, which is possibly a reason why it has not been very popular.

I also haven't used it for some time due to this fact and will need to do some refreshing on the steps, but I can start with more details to point 1) and you can also do some reading on the FLASH capabilities in the device. Note that the full details are not contained in the STR91XF user's manual but instead in a second ST document dedicated to the FLASH module. If you don't have this yet I recommend downloading it from the ST Micro web site and reading through it.

PART 1) The FLASH is the STR91XF must be configured to either boot from bank 0 or bank 1 as required

First of all, the general details of the FLASH. The STR91XF can be ordered with various sizes of internal FLASH (and SRAM). What allows the chips to have such large FLASH values (I believe up to maybe 1 or 2 MByte is offered today) is because the FLASH is a second module in the chip - the FLASH does not share the processor's silicon die.

As reference, lets take the STR912F which has 512k + 32k FLASH and 96k SRAM.

The FLASH is divided into two banks. Bank 0 and Bank 1.
- Bank 0 is a 512k block of FLASH which is made up of 8 x64k sectors. The sector size is the smallest size that can be deleted.
- Bank 1 is a 32k block of FLASH which is made up of 4 x 8k sectors.

The chip has a configuration option which allows it to either boot from bank 0 or from bank 1. This configuration option is programmed in a special, dedicated FLASH area which can only be programmed via JTAG. This means that it can only be programmed by connecting a JTAG interface (debugger) which can perform the programming using a suitable program on the PC).

The bank that is configured as boot bank is always situated at address 0x00000000. The second bank is initially deactivated. The size of the banks and the activation of the second bank is performed in initialisation code before they can be fully used.

The simplest case is to leave the configuration with bank 0 as boot bank since the chips are delivered like this (assuming this can be relied on and no one else has changed it in the meantime). This configuration is however not very good when working with a boot loader. The reason is that the boot loader (which is usually quite small) needs to occupy a complete 64k FLASH sector at the start of bank 0. When a boot loader is used it makes sense to boot from bank 1 instead, where it occupies just a small block (usually 8k).

The 64k FLASH granularity is is a little difficult to work with and the STR91XF project is usually configured to use the large-granularity mode (see http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDF for full details).

Whichever configuration is chosen, it usually makes sense to have the uParameterSystem in bank 1 (the one with 4 x 8k sectors). This is because 64k blocks for parameters is mostly overkill and wastes program space. 8k blocks are usually much more suitable.

Finally note that the FLASH sectors are protected by default. Before they can be used they need to be unprotected. The uTasker project includes automatic un-protection and protection of the sectors on a per-use basis so that the FLASH is in the protected state when the code is not presently writing or deleting something.

What this boils down to is that we need to know how to configure a project  for bank 0 booting and for bank 1 booting compatibility. We need to know how to configure the chip to match this too. These are the points 2), 3) and 4).

But point 1) is not completed until we know how to check how the chip is presently configured and how to change it if necessary. I will do some verifications (I didn't do this for some time now) since I suggest using RFlasher7 for this (you should have it alongside RIDE7). CAPs does it well but CAPs doesn't run on Vista and higher so it looks as though this method needs to effectively be dropped. I don't think that it is possible with IAR, Rowley etc. but please tell me if anyone knows better...;-)

More follows later.

Regards

Mark
Title: Re: RIDE7
Post by: mark on September 08, 2010, 08:54:40 PM
Hi

The following details how to check the configuration of the STR91XF. It assumes that the Raisonance RLink and Raisonance RFlasher7 are used.

When RFlasher7 is started it displays Project Options. Under Advanced ARM Options the processor name is set. As reference STR912FW44. This has 0x88000 code size with code starting at 0x0 and 0x18000 data size with data starting at 0x50000000. These are fixed based on the chip type selected.
Flash bank selection can be set to either bank0 @ 0x0 or bank1 @ 0
High bank address can be set to various values, as reference 0x80000

There is also a display called Panel [RFlasher7] with some connection test buttons. "Connect to RLink" and "Connect to target" are useful for verifying that the RLink is responding and that the target is also connected correctly.

The button "STR9-specific options" can be used to read present programmed configuration settings, to delete settings and program new ones. When this is opened the button "Read Configuration now!" can be used to request the present values. Assuming that the settings have been erased it will be:
Configuration: 0x0000000000000000
LVD_TH = 0
OTPLOCKBIT = 0
PROTECTMAINFLASH = 0x00000000
PROTECTSECFLASH = 0x00

There are 64 configuration bits (Configuration) and some of them are interpreted. It is clear that half are for protection of the main FLASH, some for protection of the secondary FLASH, [main FLASH is bank 0 and secondary FLASH is bank 1], some low voltage threshold and lock bits - the boot select bit is not explicitly interpreted but, since all are 0 it is presently bank 0.

To configure boot from bank 1 the "Flash bank selection selection" in the "Advanced ARM Options" needs to be configured as bank1 @ 0x0. This needs to be set before opening the "STR9 specific options" dialog. When this is the case and "Program Configuration" is checked the button "Program Configuration now!" will write the configuration. Now, when the "Read Configuration now!" command is executed it will display Configuration: 0x0000000000000d00. In fact the 0x100 is the bit controlling the boot bank (there are two other bits set which seem to be low voltage detector settings and the bit positions don't correspond with the ST FLASH Programming Manual (the bank select bit is defined as bit 48) but it is consistent and does work...

If the setting bank0 @ 0x0 is set and the configuration programmed the result is Configuration: 0x0000000000000c00 and the chip then boots from bank 0.

This means that we can now simply check the boot bank configuration of the FLASH chip (including such things as FLASH sector protection). We can also configure the chip to boot from bank 0 or bank 1.

Note further that the options in this setting influence the behavior when programming code to the device and also how the RIDE7 debugger programs. There are check boxes to specify whether the main FLASH (bank 0) or secondary FLASH (bank 1) are actually programmed or not. Also whether the configuration is programmed. This means that, once set up correctly for a project, the debugger will automatically perform all settings...

Actually RIDE7 / RFlasher7 is not such a bad solution after all ;-)

Regards

Mark

Title: Re: RIDE7
Post by: mark on September 08, 2010, 09:35:55 PM
Hi

I have tested a working version of a stripped down V1.3 project compiled with RIDE7 and downloaded wither with the RIDE7 debugger or else with RFlasher7. This uses the simplest configuration with the device booting from bank0 and all code there.

These are the changes that I made:
1) In config.h disable ETH_INTERFACE. This removes everything to do with Ethernet (including TCP/IP stack and services) so that the code is small. RIDE7 does not allow debugging code larger than 32k in size if it is not licensed. There is however no restriction to compiling larger codes and downloading them with RFlasher7.

2) I needed to make a change in the STR91XF driver since the GCC variable initialisation was missing :-/. This is here: http://www.uTasker.com/software/V1.3/STR91XF.zip

3) In the linker script file uTaskerV1.4_FLASH.ld (in \Applications\uTaskerV1.3\RIDE_STR91XF) the FLASH memory map needs to be set to
FLASH_START = 0x0000000;
FLASH_SIZE  = 0x40000;


MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00010000
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
}


This locates the code starting at address 0x00000000 where it needs to be in the simple case (it was at 0x80000).

4) In the Ride7 project "Flash bank selection" is set to bank0 @ 0x0 (see previous post)
and the script file is set to
\Applications\uTaskerV1.3\RIDE_STR91XF\uTaskerV1.4_FLASH.ld (rather than the "Bare Minimum " loader version.

After making these changes it should be possible to load the code from the debugger - just command "Debug | Start" or click on the corresponding symbol. You need to be quite patient since it takes 20s or more, after which you can then step in the code or let it run. The debugger is not very fast but does seem usable (better than the Ride4 version that was didn't do much useful at the time...)

If not debugging, loading form RFlasher is faster .

I compiled my test version for the Raisonance REva hardware. The code doesn't do much but is seen to operate due to the linking LED D0.
To test on other boards the corresponding board can be selected in config.h or else the watchdog LED needs to be configured to a different location to suit. In any case a blinking LED (heart-beat) is always good to start with.

Good luck

Mark


P.S. Exercise to test the configuration once the simple test code is running:
- try modifying the configuration to boot from bank 1. This will stop the board from running since bank 1 is empty
- then try modifying the configuration back to booting from bank 0. The board will then run again without the need to re-program the code.

Title: Re: RIDE7
Post by: Sacha_D on September 09, 2010, 08:34:10 AM
Hello

I have RLink in STD version. Have you an upgrade serial number to Pro version? I don't see reason to buy it for 700 euro for single controller without using it in future. With 32K limitation i can't debug 260K .elf file.
If you have it, please, send me by e-mail.

With hope,

Sacha_D
Title: Re: RIDE7
Post by: mark on September 09, 2010, 09:50:55 AM
Hi

I don't have a professional version and so can't help here. I believe that the keys are locked to the RLink and so exchanging keys is not possible (and is also probably not really legal).

The ELF file is large since it contains a lot of additional information for the debugger. As long as the binary is less that 32k you can debug. By removing the Ethernet support it is easily below 32k in size. Therefore don't look at the size of the ELF since it is not important.

You can still compile and load larger files but debugging with Ride7 is not possible. Debugging can still be done with the uTasker simulator (should be adequate and faster in 95% of cases) and, if necessary, by working with debug messages on the target. This means that there is no absolute need to have a source level target debugger - it does make some work easier but one can live without it (as long as some additional time is taken into account in case some problems need to be solved where the debugger would have helped - professionals will generally always use a good tool since it is important, and much cheaper in the long-term, to be able to work efficiently - students and hobby users may have different priorities).

Regards

Mark
Title: Re: RIDE7
Post by: mark on September 09, 2010, 01:30:23 PM
Hi

I would now like to take a look at point 2) The project needs to be linked to match the FLASH configuration

This is in fact quite easy to explain since the goal is to simply link the code to the correct FLASH bank depending on how the banks are configured. There are two cases for an application program: Note that the application can be either a 'stand-alone' application or an application that works together with a boot loader. When there is a boot loader present it is always linked to the boot bank.

Case 1 - stand-alone application.
In most cases the FLASH will be configured so that bank 0 is used as boot bank. This is the larger FLASH bank where the application will start at the beginning (the reset vector) and occupy a certain amount of space, depending on its size. The following sectors are then free for use by the file system, for example.

The location of the code is controlled by the linker scrip used. The script uTaskerV1.4_FLASH.ld can be used in this instance and has the following definitions for the memory space:

RAM_START   = 0x04000000;
RAM_SIZE    = 96*1024;
FLASH_START = 0x0000000;
FLASH_SIZE  = 0x40000;


MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00018000
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
}


This will cause the code to be linked starting at the address 0x00000000, which is all that is required to generate a suitable binary for this case.


Case 2 - application for operation with a boot loader
In this case it is assumed that the FLASH is configured to boot from bank 1 (the smaller bank) and this smaller bank contains a boot loader. The boot loader may allow the application to be loaded (via UART, USB etc.) and copies the application into the larger FLASH bank. For our discussion the larger FLASH bank (bank 0) is assumed to be located at 0x80000 since this is in fact programmable at run time.

The location of the code is controlled by the linker scrip used. The script uTaskerV1.4_FLASH_BM.ld can be used in this instance and has the following definitions for the memory space:

RAM_START   = 0x04000000;
RAM_SIZE    = 96*1024;
FLASH_START = 0x0080000;
FLASH_SIZE  = 0x40000;

MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00018000
    FLASH (rx) : ORIGIN = 0x00080000, LENGTH = 0x00040000
}



This will cause the code to be linked starting at the address 0x00080000, which will generate a suitable binary for this case.

To summarise: this is in fact quite a simple detail and basically involves choosing the correct linker script to be used by the project. The result is simply that the code is linked to operate at either 0x00000000 or 0x00080000. It is possible to check that the code is linked to the correct place by checking in the map file that the compiler generates or also inspecting a hex file that it generates.

However it is important to understand that this change also requires the FLASH to be correctly configured (as discussed in a previous post) and requires a boot loader to be able to work in the second case. Furthermore the non-boot bank is not enabled by default and its exact location in memory is not defined, so it requires a little initialisation code to go with it. This will be the subject of the next post...

Regards

Mark
Title: Re: RIDE7
Post by: Sacha_D on September 10, 2010, 11:05:18 AM
Hello

Today I get self-soldered(or sweated, or brazed - I don't know English well) connector from RLink device to Flash-link pins on board. In RIDE7 with RLink I can program it and erase, but can't debug, or, simply, pause execution of program. I always get message from OPI Driver: "Core does not acknowledge."

How to debug it?