Topic : Systick interrupt problems

Forum : ARM

Original Post
Post Information Post
September 10, 2010 - 2:15pm
Guest

Hello, It's still me with my updates problems.

I downloaded and installed the new version of Ride7, ( 7.30.10.0159) one week ago, and I'm using my code and MY librarie ( V0.3 ) The code work since a long time now but, like two other posts, the systick interrupt don't work since the update. All the code is OK and work perfectly on my device, but when I have a Delay, the code crash ( like in a while(1) ). I tried to go in the crt0_stm32x_HD.c file, but it's ok ( tried to change the position of "Systickhandler", but it is in a good position, like seen in the post of tr, the 18th of february 2009).

Now I don't know what i have to do, and really regret more and more having make the update.

I found an other computer with a latest version of Ride7, the same used to write my code, and the code work perfectly, and I have no problem with the systick interrupt.

I saw an other post on this subject, but there is no solution, it is the post of MicroP1, the 2nd of february 2010 named "Difference between Version 7.14.0001 and Version 7.24.09.0251"

Thanks for your help !:)

Replies
Post Information Post
+1
0
-1
September 13, 2010 - 12:05pm
Raisonance Support Team

Hi,

You may have problems with the ST libraries, which have changed over time (so ensure that you do not use the built-in ST libraries, which may help).

However, we have limited knowledge about the internals of STMicroelectronics devices, and even less about their peripherals.

We suggest that you contact the ST support team for more help on this issue.

Regards,

+1
0
-1
September 16, 2010 - 10:02am
Guest

Hi,

I know the the library change since a long time now, but the problem is not here and I'm sure of that. I don't use the ride's library ( desactived the option in ride) ,and I have MY library in MY project ( the .c and .h files). OK my library is old ( V0.3) but it's ok for me.

When I open and build and debug my project on ride version 7.30.10.0159 with the ride7 patch V7.30.10.0169 and with the rkit arm 1.26.10.0130, the systick interrupt don't work !!! ( a sort of while(1° and I did seveveral test on it.
BUT when I open the SAME PROJECT with the SAME library, without changing anything, but with the ride V7.01.0002 and the rkit arm 1.03.0004, the systick interrupt work PERFECTLY !

For that, I'm sure now that it's not a problem of library !!!

Maybe the startup file, but it is the same !!!

Why I have this problem ??

Thanks,

+1
0
-1
September 16, 2010 - 10:19am
Raisonance Support Team

Hi,

For sure there are people who use the systick interrupt with the latest versions of Ride7, RKit-ARM and ST lib.

How do you observe that "the systick doesn't work"?
Did you set a breakpoint in the ISR?
Do you just observe some memory location that the ISR is supposed to modify?
Did you try the systick example provided with the latest version of the lib?

One of the differences between these versions of the RKit-ARM is the version of the compiler. The new one optimizes a lot better.

So in some cases, like some delay codes or variables shared between main process and ISRs, the compiler will generate very different (but valid) code. The typical mistake is that a variable is not declared volatile when it should be. This was going unnoticed with old versions of gcc but new versions optimize this much better and these coding errors now trigger functional errors.

Typically, things like this (erroneous) code were making a delay before, but not now:

void delay(unsigned long cnt)
   {
   while(cnt--);
   }

The C standard permits the compiler to remove all the code in this function as optimization. The old gcc didn't do it, but the new one does...
It should be rewritten this way:

void delay(unsigned long cnt)
   {
   volatile unsigned long mycnt=cnt;
   while(mycnt)
      mycnt--;
   }

I suggest you make sure that any delay function uses a volatile variable for counting.
And also that any variable that is accessed by both the ISR and the main process (or another ISR) is declared as volatile.

You might also give a try at disabling optimization. If that makes the problem disappear, then you can be sure that it comes from a coding mistake, probably a missing 'volatile'. If the problem persists, the test doesn't prove anything.

Now, if I remember correctly, the old library code itself included some of these wrong codes. (delays optimized out, etc.) So I wouldn't be surprised if the old lib wasn't working with the new compiler at all. I would either use the old lib with the old Ride, or the new version of everything. Don't mix versions too much, as you end up using configurations that nobody else tested before...

Best Regards,

Vincent

+1
0
-1
October 5, 2010 - 9:26am
Guest

hi people,

there is no problem with your project herveTT and even not with Ride Version. this is the problem of library mismatch. you are using older version but startup file initializes your controller for newer syntaxes.

very first thing you do is just change your interrupt name. change "SysTickHandler" to "SysTick_Handler" with out any change in your project.

if this does not work show me your SysTick initialization code here so we can see the problem.

when the problem is removed, i suggest you to use newer library for your future work just to ignore such clashes

regards