MTIM-MCOMP-MPRSR

[luter]

Posted on September 23, 2005 at 04:40

MTIM-MCOMP-MPRSR

[luter]

Posted on May 17, 2011 at 10:18

Hi.

I realized a very strange mc behavior. My settings: voltage,sensor,autoswitch mode with simulated com interrupt. What happens? Sometimes i get very strange values in MCOMP which i have never set. I undestand autoswitch mode with sim com interrupt like this: only program code can write values in MCOMP what causes com interrupt. but let's have a look on fig 90, page 165, an about ST7MC1 ST7MC2. First: steps in case of mtim overflow we see division of MCOMP. does it have any influence on flow of program if com int has already occured and no write in mcomp has been done? if such division plays role of write access we get unexpected com interrupt. next problem. let's assume 1 has been written in MCOMP and directly after this write access overflow of mtim occurs, what leads to right shift of MCOMP (MCOMP>>1 equal 0). 0 is not allowed in mcomp!!! Next question. Let's have a look on Z capture and underflow event. We see the bar with ''Compute MCOMP''. for a hardware commutation it could be ok, but what about sim commutation. if com int has already occured and no access in mcomp has been done. occurres z capture with mtim underflow what calculates some value and leads to next com int. but i don't need this value, i need exactly mine. I suppose it should be notice for this bar ''only for hardware commutation''. May be I understand wrong this algorithm. if I do, please correct me. P.S.:i realized such strange behavior exactly when changes of mtim timer prescaler occure. I didn't enable RIM int. Please, make clear all this for me.

[gaetano]

Posted on May 17, 2011 at 10:18

Hi Luter,

you wrote:

Quote:

''does it have any influence on flow of program if com int has already occured and no write in mcomp has been done?'' Answer: the automatic division by 2 of MCOMP register during an overflow occurence of MTIM doesn't validate (or generate) a new C comm event. You wrote:

Quote:

let's assume 1 has been written in MCOMP and directly after this write access overflow of mtim occurs, what leads to right shift of MCOMP (MCOMP>>1 equal 0). 0 is not allowed in mcomp!!!

Answer: If MTIM is near to go in overflow, that means it is at its higher value (of course not above 255 as the overflow occurs for MTIM=100h, cf. fig. 90); as soon as you write 1 in MCOMP, as this value is less than the actual value of MTIM, a C event will be generated immediately, and MCOMP register will be overwritten by MTIM value (cf. par. 9.6.7.4). After overflow occurs, MCOMP will be divided automatically by 2 assuming a value equal or less than 7Fh and MTIM will be put at 80h (cf. par. 9.6.7.2 subpar. b) ). So no risks exist to have MCOMP=0 as you worried about. You wrote:

Quote:

Let's have a look on Z capture and underflow event. We see the bar with ''Compute MCOMP''. for a hardware commutation it could be ok, but what about sim commutation. if com int has already occured and no access in mcomp has been done. occurres z capture with mtim underflow what calculates some value and leads to next com int. but i don't need this value, i need exactly mine. I suppose it should be notice for this bar ''only for hardware commutation''. Answer: Looking at figure 95, I can suppose you are in the third case (that is, SC=1 when Z event occurs). Well, if it is the case, when Z event occurs (with or without an underflow), you MUST write a new value for MCOMP to be able to generate the next C event (because no hardware multiplication occured during Z event in this case). But this new value cannot be the same as the previous one, as now the ratio has been changed, that is, decreased. To keep the same time interval between the Z event and next commutation, you have to double ''manually'' the new value for MCOMP so taking into account the changing in the prescaler ratio. In the RIM ISR (if you enable the relative mask bit), for instance, you could set the propoer value for MCOMP register. I hope now it is more clear... Regards, Tanio

[luter]

Posted on May 17, 2011 at 10:18

Hello.

Really tnx for help. I hope you get money for it. I found my mistake. as ussual the source was not there i was looking for. Could you suggest me how to do delay between z and c int as short as possible. My way: i use autoswitch mode and sim com interrupt. software priority of com int is higher than z int. what i do. in the beginning of z int i do ''MCOMP = 0x1''. it causes validation of com int. since priority of com int is higher than priority of z int and mtim counter is higher of equal to 1 it causes interruption of Z ISR and start of C ISR. what is the problem? i realized what c int occurs not immediatelly after ''MCOMP = 0x1''. it occurs in 8-18 opcodes (10-30 microsec). how to make this delay shorter? i would like to use autoswitch mode because i need high-precision speed calculation. any ideas? Beer is still waiting for you... :-]

[gaetano]

Posted on May 17, 2011 at 10:18

Hi Luter,

really, I'm not work for the money but for the beer (you know) ;) . Skipping on more serious things: starting from your hypothesis, when you write MCOMP=0x1 as first instruction of Z ISR, the C event cannot be validated immediately (as you liked) as it depends on the effective value of MTIM timer, that could be still equal to zero (don't forget that a Z event is occured just before). As you can easily understand, the time between the Z and next C event depends, in this case, on the prescaler ratio value: as bigger it is much more time elapses before next C event generation (the time needed to MTIM to switch from 0 to 1). Although it is forbidden by the datasheet, try to put MCOMP=0, this should work as you want. I'm verifying about eventual undesired effect on this approach. I hope it is clear and solves your problem. By the way, when does the OKTOBERFEST begin in Germany...? :) Aufwiedersen, Tanio

[luter]

Posted on May 17, 2011 at 10:18

Hello.

Now everything is clear. You confirmed my hypothesis and i'm sure that i'm on the right way. Tnx for help. P.S.: Main Oktoberfest in Bayern has already started, but regional Oktoberfests last the whole year round. Tschuess