STR9 V1.2 library New Release and MCU for optimum CPU performance

[amira1]

Posted on July 20, 2007 at 07:44

STR9 V1.2 library New Release and MCU for optimum CPU performance

[amira1]

Posted on May 17, 2011 at 09:44

Hi all,

Following your demand/requests on this Forum we have updated our library

With a new release 1.2 that should correct all reported limitations on these Threads. You can refer to our main Download page where you can find the Latest zip file with all release notes.

A Great Thanks for all contributors on this forum :)

Moreover, we have also released an new application Note AN2551 :

''Configuring the STR91xFA MCU for optimum CPU performance'' that explains in

A simple way all STR9 Options to be taken into account to get the Maximum

MIPs. But you have to tune your preferred toolchain to maximum Speed,

for example : You can see the image below for IAR Workbench and the same for Ride from Raisonance Using GCC, RMDK from Keil and RVDK from ARM and all others.

Thanks again for your inputs.

With best regards,

Mirou :-]

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Hi

After using the STR91XF at the default 48MHz for some time I have just followed the new AN2551 to get up to 96MHz.

However I have experienced something quite worrying.

When I set the PCLK to divide by 2 the processor runs at 96MHz but the timers (used for example by the TICK) don't count. Other peripherals are fine - like the UART which is operating at 115200 perfectly.

If I clear the divide by 2 bit (0x08 in SCU_CLKCNTR) using a debugger, the timers count correctly and the system runs correctly. On setting the bit again the timer's count value is frozen and the system is running without a TICK again.

This is reproducible on a board with a STR911 and a board with a sample of the new revision of STR912F (I think Rev. F).

I have therefore left the bit not set - PCLK is supposedly running at 96MHz, which is twice too fast according to the AN but is the only way that the system operates at the moment.

I don't see the relationship between the divider and the timers (?)

I am also quite sure that the chip is operating at 96M because a reference calculation (quite a long private key generation from a certicicate) took about 40s at 48MHz and now takes about 20s with the new setting.

The same calculation has been measured to complete 13% faster using the Rev. F device and its improved BP operation.

Can you or anyone else comment on my observations. I am very nervous at using the device at 96MHz since the PCLK is probably way out of spec, but at the moment any attempt to reduce the PCLK speed results in the system TICK being frozen.

Thanks in advance.

Best regards

Mark Butcher

http://www.uTasker.com

/

http://www.mjbc.ch

[alandras]

Posted on May 17, 2011 at 09:44

Quote:

If I clear the divide by 2 bit (0x08 in SCU_CLKCNTR) using a debugger, the timers count correctly and the system runs correctly. On setting the bit again the timer's count value is frozen and the system is running without a TICK again.

Isn't this related to

2.32 16-bit pre-scaled clock source for general purpose timers

from the latest errata?

Silicon Limitation: The clock source from fMSTR through the 16-bit prescaler does not operate correctly and cannot be used. The 16-bit prescaler does not output the expected clock pattern.

Andras

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Hi Andras

Thanks for the tip. I have updated my errata sheets and read about the timer problem for the first time.

However I don't think that it is that in this case. I have checked and see a mistake with my previous statement about not seeing the relationship between PCLK and the timers. I am in fact using PCLK/256 as input to the timer.

The errata is about using the external clock with 16 bit divider and says that the PCLK input has no errors.

This is however jogging my memory about problems which I had when starting working with the STR91 and programming the timers. I had difficultes getting the speed correct since the divider didn't always seem to divide by the value expected (and it was even giving intervals of varying lengths - one TICK would be x and the next TICK would be 2x and other wierd things). Now it may be that I was origianlly experimenting with the external clock source fMSTR/divider but I am not absolutely sure.

I note that when using PCLK/1 and then timer input /256 all is fine.

When using PCLK/2 and then timer input /256 the timer stops counting (count value freezes) therefore I will have a go with different timer input divide ratios - perhaps there is an issue with /256 after a PCLK divide or something similar. Therefore I have some experimenting to do over the weekend...

Regards

Mark

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Hi again

After some experimenting I could in fact get the timer to run by setting certain clock divides (eg. 0x70 works but 0xff didn't).

But then I realised that I was indeed using the external clock and the divide which I was playing with was not the divide from the PCLK but rather the 16 bit divider which has the bug in it. So in fact this is the known problem after all.

After selecting the PCLK rather than external clock as timer clock input and dividing PCLK by 256 (as I was doing with the external clock) it is now operating correctly. The system TICK is fine and a second timer output generating key beeps is also good.

I do however have an open question about the STR912F that I am using (which also has the problem). According to the errata this Timer problem affects engineering samples Revs. B and D. I understood that I had a Rev. F sample, which I was also asked to report perfomance on. It has the marking ''F ES'' on the LQFP128 package. This is not shown in any of the Errata/limitations documents. Any ideas???

Regards

Mark

[roger_lynx]

Posted on May 17, 2011 at 09:44

I understood that I had a Rev. F sample, which I was also asked to report perfomance on.

 

It has the marking ''F ES'' on the LQFP128 package.

 

This is not shown in any of the Errata/limitations documents. Any ideas???

Engineering Sample of Revision F?

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Here's the full chip marking:

ARM F ES

STR912F A

HPAEB V6

KOR DA 704

ST

Cheers

Mark

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Hi

I thought that all was fine but now I have quite different results with a project with the STR912F and operational Ethernet (don't know whether this has anything to do with it but it is a difference to the previous project I was testing on. It is also possible that I just didn't notice that it was too fast there.).

When I run at 48MHz I have a TICK running at 50ms. There is a task controlling an LED which is inverting the output every 200ms (4 ticks).

Here PCLK is the same as RCLK = 48MHz. (SCU_CLKCTRL = 0x00021000).

I noticed that when running at 96MHz (PCLK = RCLK/2 SCU_CLKCTRL = 0x00021080) the TICK was twice too fast. The LED was blinking twice the expected rate (once every 100ms suggesting TICK is 25ms rather than the expected 50ms).

So I tried debugging. First with an early Rev. B [610 marking] part. I found that I couldn't debug at 96MHz which is probably due to the known system reset problem at 96MHz.

So I moved to my Rev. F part and could debug. These are the results.

SCU_CLKCTRL = 0x00021000 TICK 25ms

SCU_CLKCTRL = 0x00021080 TICK 25ms

SCU_CLKCTRL = 0x00021100 TICK varying between 25ms and 50ms*

SCU_CLKCTRL = 0x00021180 TICK 50ms

* The LED pattern was 100ms,100ms,200ms,100ms,100ms,200ms etc.

This means that in order to get the expected PCLK I have to divide by 8 and not 2 (!?)

Whether I divide by 1 or 2 gives the same result (div. 1)

If I divide by 4 the clock is no stable(!!?)

Now I am really wondering whether I am going mad...?..?

Is there perhaps also a problem with the PCLK divider?

Regards

Mark

www.uTasker.com

[kais]

Posted on May 17, 2011 at 09:44

Hi Mark,

I've tried this config (using PCLK/2 and, timer input /256 , CPU running @96 MHZ) but Timer still counting very well!

So I’ve tried to help you However I was unable to reproduce your issue.

I think it will be better if you send through your project.

Kind regards

eris.

[m_j_butcher]

Posted on May 17, 2011 at 09:44

Hi Eris

I have found that I have no problem with STR911-REV.G at 96MHz but my STR912-REV.F does.

However I may receive an STR912-REV.G soon.

Since I have also older STR912 I am using the Ethernet projects at 48MHz zu avoid any issues.

For the moment I am not doing any more tests here but there are a few Beta testers of our OS and TCP/IP stack which will hopefully give feedback to identify whether it is a chip or project problem. They tend to have older chips on teh demo boards (of course)

Regards

Mark