µTasker Forum > STTM STM32 and STR91XF
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: ---#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)
--- End code ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version