Author Topic: RIDE7  (Read 36247 times)

Offline guibiao

  • Newbie
  • *
  • Posts: 10
    • View Profile
RIDE7
« 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

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #1 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

Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #2 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.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #3 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

Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #4 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?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #5 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

Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #6 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.
« Last Edit: September 06, 2010, 12:11:31 PM by Sacha_D »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #7 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

Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #8 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?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #9 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



Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #10 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?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #11 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.



Offline Sacha_D

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: RIDE7
« Reply #12 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?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #13 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

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3232
    • View Profile
    • uTasker
Re: RIDE7
« Reply #14 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