STR91XF Pre-release

[mark]

Hi All

Please note that the state of the STR91XF project is pre-release but any one who would like to use it and/or help to complete final tests and fine tunings is welcome. Simply fill out the standard application form to get a link and password to it.

Please use this thread for feedback and I will be using it to inform of patches and other details during the last phase.
Note that a couple of updates are included from the past to ensure than anyone watching is up to date.

Regards

Mark

[mark]

Update 1: http://www.uTasker.com/software/STR91XF/STR91XF_Update_1.zip

Hi all STR91 users / testers


1. CPU Speed.
To set the PLL speed there are the following defines in app_hw_str91xf.h.

Code: [Select]

#define CRYSTAL_FREQ    25000000                                         // crystal or clock input frequency (4 to 25MHz)

#define OSC_DIVIDE      25                                               // 1..255

#define PLL_MUL         192                                              // 1..255

#define POST_DIVIDE_EXP 3                                                // 0..5 (3 for 48MHz, 2 for 96MHz)
 

You no doubt know that the STR91 can operate at up to 96MHz. This setting is however for 48MHz operation. The various register settings can be modified to generate various speeds and there is a checking routine which will cause a compile error to be generate if the user tries to set anything with an illegal value (eg. the PLL intermediate frequency must be between within 200 and 622MHz ). See the users’ manual for detail – section 2.4.

To work with 96MHz clock POST_DIVIDE must simply be set to 2 instead of 3.

Note also that when the uTasker simulator is running it displays the exact PLL frequency that the CPU would be running at.

Running at 48MHz is no problem. However to achieve fastest operation there are a number of settings which have to be correct. I have used the ST application note http://www.st.com/stonline/products/literature/an/13563.pdf as reference.

The project does however adapt itself according to the PLL. For example, the PCLK should not be faster than 48MHz and so dividers must be set when the PLL is greater. Then the FLASH wait states has to be increased when operating at over 66MHz. See fnSetFMI() in str91xf.c – here I have had to make a correction so that it operates correctly from bank 0 and bank 1 at all selected speeds.

Then there are some new errata. It is best to collect these from the ST web site. One important point to note is that the original chips (rev. B and D for example) have a problem at 96MHz which means that a reset is only effective when it is a power up reset – this means that debuggers can not really work at 96MHz- check the chips you have on your boards to see whether you have this limitation!! If you do (which is unfortunately very likely), stick to 48MHz for the moment.

There are also some errors (also in the last silicon) to do with clock dividers. In fact I got caught out and I still believe that there is another bug which means that it is in fact necessary to set PCLK to RCLK/8 to get it to divide by 2!! See the following forum discussion for full details about the state of development: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5460&forum=21

 
2. PHY. I tested the PHY and found that although it is responding correctly I am not getting the expected interrupt on link up/down. I also found out that the ST PHY doesn’t correspond to the typical PHY register set so I have had to change the defines for it in the header file. This is an open point – see the following forum posting for more details: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5489&forum=21

 
However this doesn’t actually affect normal operation – there is just no link up/down events of they were needed.

3. I have added low power support (define SUPPORT_LOW_POWER in config.h) but haven’t actually verified it yet… This uses the IDLE mode of the chip to stop the CPU clock when there is no processing to be performed. As soon as a peripheral interrupt arrives it should continue operation. I have used this successfully with the Coldfire and the SAM7X so I am hoping that it also works well on this chip.


Plan of attack:
- I still have to test the boot loader. The project compiles and I have already successfully used the boot loader with the chip (although not yet over Ethernet).
Since the boot loader occupies only 2k of an 8k FLASH block in Bank 1 I think that it will be useful to add also loading via UART.
- Then I plan to configure a RIDE GNU project (I have successfully used RIDE with the STR91 but it is some time ago and needs main and boot builds).
- Once the RIDE project is good there will be a GNU build but I would then like to use a stand-along GNU build and probably an Eclipse project with it.


If you have any remarks or results from your own tests please let me know.


Thanks for your help.


Best regards


Mark

[mark]

Update 2: http://www.uTasker.com/software/STR91XF/STR91XF_Update_2_RIDE.zip

Hi STR91 Users


This upgrade adds a Raisonance RIDE project which builds with the GNU compiler.

The Raisonance kit is useful since it includes the low cost RLink JTAG debugger (works very well with ST CAPs program) and several STR daughter boards to insert into the REva development board. It includes the RIDE IDE which allows building complete GNU projects but has limited debugging (16k in RAM). When I bought mine it was on special offer from EBV at €99.

Raisonance has a very good forum where questions are answered very quickly - http://www.raisonance.com/Forum/punbb/viewforum.php?id=6

 
This upgrade updates the str91xf.c hardware file with a small modification for GNU. It also includes a start up file for GNU which I have modified from the original delivered by Raisonance due to errors and missing initialisations that it originally had. This should be placed in hardware/str91xf.

The RIDE project directory (RIDE_STR91XF) should be placed in application\uTaskerV1.3\ It contains the project and linker script to suit the project as well as downloadable code which I generated. To open the project simply open utaskerv1.3.prj in the RIDE IDE (drag and drop to the IDE works as well).

I am hoping that it was possible to make the project completely ‘relative’ so that it will work without having to set any paths. Please tell me if it necessary to modify anything to get it to work on another machine.

Here are my notes and some issues that I have had with RIDE 06.10.22, Build number BN745-ST7-ARM-80C51 (there is a new patch available but I haven’t tried to see which of the problems are solved by it)

1. Whenever I build (Make) all files are recompiled. I can't find the make file being used and don't know what the problem is.
2. Each time starting debug mode the project is rebuilt (all files as in 1) and I don't find a method of setting the debugger not to rebuild each time (which is possible in most IDEs).
3. The download time is very long (including the problem 1) - about 1 minute each time. [Comparing with other IDEs which I also use, this is about 10x slower, even when the others program to FLASH rather than to SRAM].
4. Stepping through code is also very slow - other IDEs are also about 10x faster.
5. The internal peripheral register view seems to be restricted to a few like SCU and GPIO - the many others are not there and can only be looked at by viewing their memory addresses.
6. The object and list files created when compiling each file are being put into the same directory as the file. Thsi means that the project base (shared by various processors and compilers) gets full of many files which then have to be removed manually. Is there a set up possibility to compile to a central directory (as possible with most other IDEs - eg. to debug or release or object directory etc.)
7. It doesn't seem to be possible to add header files to the project - when these are added the compiler tries to compile them and the build fails. This means that configuration files have to be searched for and opened in order to change them which is not very nice.
8. I haven't found a method in the IDE to set the generation of a PSA files (objdump).

 
Note that this is a list that I compiled quiet a time back. Raisonance answered my question and some of them may have been solved in the meantime. The original post is here: http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2068


A new problem which I found is that my IDE doesn’t correctly set the thumb mode and inter-working GCC flags. Therefore I have modified the project options to do the same thing ‘manually’. I have reported this to Raisonance [http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2247]. In the project I simply added –mthumb and -mthumb-interwork to the GCC C options under ‘more’ and -mthumb-interwork to the asm options. Raisonance has in the meantime answered this and it is thus possible in the IDE.

My tests of the code running on my board were successful with one exception. A GIF image on the start side of the web server doesn’t load. It sends an empty TCP frame where the start of the GIF is expected. The same project runs correctly when compiled with the IAR compiler and an equivalent build with GNU for Coldfire also runs correctly so this must be a local compiler issue. I haven’t attempted to debug it yet– it  since I also only have the Light version of RIDE (I debugged the port with my IAR debugger from FLASH in assembler mode which was not so difficult, but this could be rather more complicated in assembler mode…).

For those with the REva and RIDE I would be grateful for feedback on whether all works for you – possibly someone can also take a look at the known problem with the GIF.

My next step will be to make a stand-alone build for GNU (using CodeSourcery package) – theoretically this should not be too difficult since RIDE is also GNU based and I hopefully solved the main difficulties (mainly in the LD and the start-up code). It may then be possible to debug with Eclipse (see James Lynch’s later article for the SAM7X – I am hoping that it will also be possible with the STR91: http://www.megaupload.com/de/?d=U1MBMEIU ).

Good luck

Regards

Mark

[mark]

I have been following a discussion about IDLE mode on the STR91XF.

See: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5658&forum=21

What I didn't notice originally is that there is a bug with the idle mode in some of the chip revisions. Code has been supplied by ST (moderator) to work around this but it is not sure that it works on all types.

Thsi is a point which also needs to be looked into in the uTasker low power mode in the STR91XF project.

If any one has tried it or the suggestions in the link it would be interetsing to hear about the results.

Regards

Mark

[guibiao]

Hi, Mark. I have been trying out the uTasker for STR91XF in the last few weeks. I like it very much, especially the simulator. It also works on the Rasonance demo board. I also tried to add a SSL layer to the uTasker. So far, it works on the simulator. I may have to figure out how to deal with dynamic memory allocation problem. I may need use static memory on my SSL. I have a few questions about the uTasker:
 1. When do the release version will be ready for the STR91XF?
 2. When I try to use RIDE debug (simulator), it runs in circle:

int main(void)
{

    ptrSeed = &usRandomSeed;



static void fnSetFMI(unsigned short usConfig)
{
    uDisable_Interrupt(); 

I am very new at the tools. Maybe I miss some obvious?

 3. When I run the uTasker simulator, sometimes it crashes at

void uEnable_Interrupt()
{
#ifdef _WINDOWS
    if (!iInterruptLevel) {
        *(int *)0 = 0;                --------crash here
    }


Again, thanks for the excellent work. I am looking forward to the release version of the uTasker.

Guibiao

[mark]

Hi Guibiao

Up until now there has not been a very high level of interest shown in the STR91XF and so there has also been little feedback about the pre-release. This makes it a bit difficult to release because this is generally done when there is adequate confirmation of its suitabilily.

There are a couple of open points on the list which need to be resolved before an official release will be made (see previous posts). Therefore I can't make any dates just yet. However if your experiences with the pre-release have proved positive it give incentive to push on more. In any case, the pre-release is always available for any one interested in using it.


I have never used the RIDE debug (simulator). I am assuming that you are running it in the simulator (rather than compiling the project and debugging it on the target). The question is whether the simulator can simulate a complete project correctly - does it handle peripherals and interrupts etc? Since the scheduler is timer interrupt driven this is the minimum that a simulator must be able to handle to get anything running.
Generally the simulators built into IDEs are useful for analysing small parts of code to verify the processors instruction set and similar jobs, but rarely are they useful for testing a real and complete application. This is where the uTasker simulator takes over and I am pleased that you are finding this useful for your work.


void uEnable_Interrupt()
{
#ifdef _WINDOWS
    if (!iInterruptLevel) {
        *(int *)0 = 0;                --------crash here
    }

This is a check which is only present when simulating. It is infact a simple method if generating an exception (assert) when the use of interrupt disable/enable doesn't correspond to that which is expected. This is in fact not a serious error but it does point out that somewhere a routine is calling uEnable_Interrupt to (re)enable interrupt when they were not blocked (it causes no other negative side effects).
Normally interrupt disables are always matched with an interrupt enable. These can also be nested (eg. 3 disables were called inside each other and then 3 enables - which would be absolutely normal).
It would be interesting to find out which routine is calling uEnable_Interrupt() in this case (look at the call stack in the simulator when it happens). Perhaps there is a minor problem which can be identified. It is also possible that it is a simulator issue due to WinPCap injecting Ethernet frames in a critical region which is not correctly protected - it would be nice to know why but, as I said, it is not serious so you can remove the *(int *)0 = 0; if you would prefer not to get the exceptions.

Thanks for the feedback on your own work. It would be interesting to learn more about your addition of an SSL layer!!

Regards

Mark

[guibiao]

Hi, Mark. Finally I got the uTasker plus SSL to work on my Raisonance demo board. The SSL uses about 50KB flash and 36KB RAM. And it runs very fast. The SSL uses malloc and free, so I have to set aside a chunk of memory (about 16KB), and implement my own malloc and free. The uTasker PC simulator helps me tremendously. Thank you very much!

Guibiao

[mark]

Hi Guibiao

Congratulations. I am very happy that the simulator has helped your work. I have also used OpenSSL on the STR91 (not SSL over TCP though) and could also save lots of time working with the simulator.

OpenSSL uses malloc/free a lot and so I simply used the IAR library in parallel to the uTasker's uMalloc(). I don't remember which compiler you are using but it is quite easy to use both in parallel. I have seen that this is not presently in the the STR91 project but in others (like Coldfire) M5223X it is possible to define GNU_MALLOC_SIZE (eg. #define GNU_MALLOC_SIZE 0x1000) in config.h to specifiy the amount of memory the GCC malloc library routine has for its own use. Obviously you could solve this to your satisfaction in any case.

Regards

Mark