┬ÁTasker Forum

┬ÁTasker Forum => STTM STM32 and STR91XF => Topic started by: jezc on July 17, 2008, 10:30:45 PM

Title: Porting to other evaluation boards
Post by: jezc on July 17, 2008, 10:30:45 PM

I've ordered an IAR STR9 dev kit but also have both the ST STR9-Eval board & Hitex STR9 dev board (and the Hitex STR9 ComStick).

Can you please tell me where to start porting the demo to one/all of these?

I've also got one of the 2M Flash parts on the STR9-Eval -how can I change the demo to support the larger banks for this processor?

Thanks in advance.
Title: Re: Porting to other evaluation boards
Post by: mark on July 18, 2008, 01:37:07 AM
Hi Jez

Take a look at config.h:
    #define STR9_DONGLE                                                  // STR eval board as USB dongle
  //#define REva_DAUGHTER                                                // Raisonance REva STR912F daughter board
  //#define STR912_SK                                                    // IAR Evaluation Board

Here you see that the demo can be configured for these three boards. The differences are in fact quite small - a few ports connected differently but the same PHY. You can search the project for these defines to see the exact differences and then add new defines (plus any changes required for each target) for each target you add. As long as they don't have different PHYs this is very easy to do. Possibly there are no changes needed for a specific board.

When using a part with 2Meg you won't have to change any thing for it to work (at least I don't think so). The program size of only about 40k so whether you have 128k or 2Meg physically available won't require any different settings. If you want to use more space for the file system you can specify different values for uFILE_START and FILE_SYSTEM_SIZE.
If you use more than 512k, change MAIN_FLASH_SIZE to the physical size (in app_hw_str91xf.h).
The only time you may need to change the linker script is if your program (code) grows to a greater size than the specified FLASH size. The linker will generate an error if this happens and you can then increase the value of
-DROMEND=0x007FFFF to -DROMEND=0x01FFFFF (512k to 2Meg) in \Applications\uTaskerV1.3\IAR_STR91XF\settings\lnkarm_flash.xcl


Title: Re: Porting to other evaluation boards
Post by: jezc on August 06, 2008, 10:12:59 PM
Hi Mark,

Thanks very much for that info.

I've now received my IAR STR9 dev kit but I'm having trouble downloading the image to the target - I've changed config.h for the IAR dev board & built the project ok (using IAR v4.42a) but when I try to download the image via the j-Link/j-Trace debugger I'm getting an error message that the uTasker 1.3 sim file is missing.

I can download other projects to the internal Flash & run them ok.

Any ideas where I'm going wrong?

Title: Re: Porting to other evaluation boards
Post by: mark on August 06, 2008, 10:54:56 PM
Hi Jez

This sounds as though your FLASHing tool needs a sim file (I think this is simple, or simple-code format).
When you compile the project using IAR it will create an output format as defined by the project options - the uTasker project is generally set up for Extended Intel HEX output so that it is compatible with CAPs (the ST programming tool).

You can therefore select any format and re-link the project:
1- Make sure you you are using the build target "Bank 0 full" which expects the FLASH bank 0 (the big one) to be booted from, and positions the program there.
2. Right click on the project in the workspace to open the options menu.
3. Select the category "Linker" and then set up the "Extra Output" tab to generate the desired format.

If you have a reference IAR project which is downloading correctly with your tools check how this is configured and then simply copy it.

Good luck



PS. In the tutorial: http://www.utasker.com/docs/STR91XF/uTaskerV1.3-Tutorial-STR91XF.PDF there is a guide to working with CAPs if you want to look at it. It is useful for configuring the internal FLASH since I don't think that this is possible with the IAR tools (or do you know better?)
Title: Re: Porting to other evaluation boards
Post by: jezc on August 30, 2008, 10:34:52 PM
Hi Mark,

I've borrowed a Raisonance R-Link to let me make faster progress & managed to program the hex file (via CAPS) ok. But when I run the code, one of the LEDs on the IAR dev board is flashing (LED9) but the board isn't being recognised by my router! I've edited the config.h to build for the IAR dev board rather than the Raisonance one and followed the instructions re CAPS in the tutorial. I've got a red power LED on solidly, a green LED next to the USB connector on solidly & LED9 flashing but no display on the LCD. Pressing the reset button extinguishes the green LED & LED9 briefly.

The green LED on the ethernet socket on the board is showing green most of the time & I see an occasional flicker of orange from the other LED on the RJ45.

Any ideas what I'm doing wrong this time?

Also, re-reading your first reply, I notice that the source snippet has a reference to the STR9_DONGLE as a supported board but the code I've got only mentions the Raisonance & IAR boards. Is there a newer version I should try?

The simulation under dev studio works brilliantly, I'm just hoping to get the real hardware working ready to start developing my own application!

Title: Re: Porting to other evaluation boards
Post by: mark on August 31, 2008, 12:32:46 AM
Hi Jez

About the STR9 dongle..I have this setup in my development version but there have not been any service packs for the STR912 so it isn't in the original code. The board is more or less compatible with the Raisonance REva daughter board but uses an STE101P PHY rather than an STE100P with a different PHY identifier and also a different MII address wired to it (0x10 rather than 0x15). I just remember configuring this and putting a demo on the software page. Since you don't use the STR9 dongle I wouldn't worry about this detail.

It sounds as though your code is now running. The power LED is on and LED9 is being flashed by the SW. I don't know about the green USB LED (mine is yellow) - it does light when the USB is connected to a PC since the PC delivers 5V to it, but otherwise I wouldn't expect it to light. Check the circuit diagram (perhaps there is a slight difference on your board) and also the jumpers around the LED. probably nothing to worry about though.

When you plug and unplug the LAN cable the green Ethernet LED should light and and then distinguish. This shows that the PHY is basically operating but doesn't tell much more that that - it usually has a default configuration which does this even if the SW doesn't work. The same is true when there is network activity, as it blinks then.

It may be normal that there is nothing showing in the LCD - make sure that you have #define SUPPORT_LCD in config.h set to add this to the demo code.

Normally I would expect the Ethernet connection to work since you have already verified that your set up is working with the simulator - that means that the network configuration seems fine.

I am wondering whether your board really does have a change - the fact that the USB LED is green is surprising since in the circuit diagram to mine it states "yellow LED". Could it be that they have changed something else - like the address of the PHY? Or perhaps a newer PHY with a different PHY identifier?

If you can debug with your tools I would check first that the PHY is being recognised - if the identifier doesn't match the Ethernet configuration will be aborted.

Put a break point in extern void fnConfigEthernet(ETHTABLE *pars) in STR91XF.c then run to the line
    if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) return;
Check whether the identifier read from the PHY is matching the define.
        #define PHY_IDENTIFIER          0x1c040010                           // STE100P identifier
If they have changed the PHY for an STE101P the following would be required:
        #define PHY_IDENTIFIER          0x00061c50                           // STE101P identifier
As you can see the STE101P has a completely different value and I think that the STE101P is a replacement for the older STE100P - it may be that the older ones are no longer delivered and so the newer IAR boards use the newer one (as the STR9 dongle does)(?)

If you read 0xffffffff it means that the chip is not responding. This will happen if its address has been changed (the address is hardwired on the board). When this happens I use the debugger to repeat the read sequence (by setting the PC back to the start of it) and modifying its address:
    ENET_MIIA = (READ_FROM_PHY | ulRegAdr);                              // command read from given address
where #define READ_FROM_PHY (PHY_READ  | (PHY_ADDRESS_ << 11) | PHY_BUSY)

Therefore modify the register prepared for the write to ENET_MIIA with values from 0..31 for PHY_ADDRESS [note that it is 11 bits shifted in the long work written] until it responds. Of course it should be possible to calculate the value from the circuit diagram after checking the pins which are used to latch the address at reset from the PHY's data sheet.

Should no response be achieved after trying all possible addresses it would seem that the board has a problem - but I think that it is probably something which can be explained.