MC56F8023 dealing with UWord32

[sandrom]

Hello all,

I'm using MC56F8023 with CW 10.7, I see examples that use 32 bit variable (declared by Word32 and UWord32).

I have some strange behavior using them, this is the code I use:

void function (void) {

   UWord32 temp = 0;
  UWord32 temp0 = 0;
  UWord32 temp1 = 0;
  temp1 = 2053;
  temp0 = (UWord32)(temp1 * 330);
  temp = temp0 >> 12;

...

}

I use temp variables here as an example. What happens is that, during debugging, temp0 variable take absurd values (usually 216268800), and I dont understand why. The original code doesnt use fixed values obviously, here are only for example.

Someone can explain me what happens? Should I not use 32-bit variables? I know the microcontroller is a 16-bit one, but if CW let me use 32bit...

EDIT: It is a interrupt-related issue, because if I disable them before operations, all is ok. But I would disable interrupt for stuff like this...what should I do? My only problem is that the multiplication could overflow the 16-bit.

Thanks in advance for help!

Sandro

[sandrom]

Hi all,

sorry for late answer, I did lot of try and I came to the the conclusion that it's an interrupt-related stuff.

xiangjun.rong‌ it is not a debugger issue, cause the problem happens even without it connected.

Look at this piece of code just to show you the problem (located in main.c file, in main() function):

prova = 1830.0;
value = FRAC16(prova / 4095.0);
 valueCompare = FRAC16(195.0 / 434.0);
while (value < valueCompare) {
    WDog1_Clear();
// do some stuff
value = FRAC16(prova / 4095.0);
 }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

As you see, 'value' variable has always the same value (both variable are Frac16).

So, this should be an infinite loop, 'value' (14643) is always < than 'valueCompare' (14722).

In fact, debugging, it enters in the while cycle, but if I put a breakpoint after the while cycle, after random (?) time the breakpoint fires! This because 'value' become 32767 (looking with debugger)!

If I disable interrupt before line 7 and re-enable after it, all is ok.

Note that if I put fixed values at line 7 (value = FRAC16(1830.0 / 4095.0), it's again all fine (infinite loop).

What should I do? I think it's impossible nobody had this problem before...

Please help me I can't enable-disable interrupt every time I need that macro.

Thanks

Sandro

[xiangjun_rong]

Hi,

as you know that the ISR is different from the generic sub-routine, because the ISR needs push/pop both PC and SR registers. Before each ISR, pls add the #pragma interrupt on so that the Compiler can generate rti instead of rts instruction at the end of routine.

for example, pit interrupt routine.

#pragma interrupt on

void pit_isr(void)

{

   //led toggle

   PORTA=^0x01;

}

pls have a try.

BR

Xiangjun Rong

[sandrom]

Hello Xiangjun,

thanks for suggestion, I tried but the result is the same. Note that I already have this pragma structure for every ISR (generated by PE):

#if defined(isrPWM_Reload_FAST_INT)
#pragma interrupt fast
#elif defined(isrPWM_Reload_VECT_TABLE_ISR_FAST_INT)
#pragma define_section interrupt_fast "interrupt_fast.text" RX
#pragma section interrupt_fast begin
#pragma interrupt fast
#else
#pragma interrupt
#endif
/**
 * comments
*/
void isrPWM_Reload(void) {
...
}
#if defined(isrPWM_Reload_VECT_TABLE_ISR_FAST_INT)
#pragma section interrupt_fast end
#endif‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I simply added the word "on" at the end of "#pragma interrupt". The pragma that is consider is exactly the one you suggest (line 6), without word "on". But, also adding "on" the situation doesn't change.

Another thing: I have these warning after compile (I still have to deal with):

Overlap of the .interrupt_vectors section and .interrupt_vectorsboot section.
Overlap of the .interrupt_vectorsboot section and .interrupt_vectors section.

Could this generate the problem?

One last important thing: if I move the code that use FRAC16 macro inside an ISR, and I do the compare in the main(), all it's fine. Maybe somewhere there is a yours guide that say that the math macros must be used insider ISR?

Thanks again,

Sandro

[dynapb · Accepted solution]

Hi Sandro,

Try changing it to

#pragma interrupt saveall

and see what happens.

Pete

[sandrom]

Hi Peter,

this seems to work! With saveall the problem doesn't happen!

Now the question is: what contraindications could lead to with this kind of pragma? 

May I go with saveall without worry?

Thanks to all!

Sandro

[dynapb]

Hi Sandro,

You should be ok with saveall.  I just recalled this issue after reading your & Xiangjun's latest comments.

I think the problem is that '#pragma interrupt on' just tries to save the used registers etc. and the interrupt call function does not seem to know about all the registers that the math fuctions use.

#pragma interrupt saveall saves the whole context so that problem does not occur.  It takes a little longer would be the only potential issue.

Pete

[sandrom]

Hi Peter, 

thanks again for the solution! I think long-time execution will not be a problem for my project, anyway I will do tests.

Thanks all for helping me!

Sandro

[sandrom]

Hello,

thank you all for the suggestions! I will try what you say, I think the problem is interrupt-related, meanwhile I made a workaround, but I would like to solve the problem, so I will try and then let you know.

Thanks again for help!

BR

Sandro

[xiangjun_rong]

Hi, Sandro,

I suppose it is debugger issue. From your code, you see that the following variable UWord32 temp = 0;
  UWord32 temp0 = 0;
  UWord32 temp1 = 0;
  temp1 = 2053;

are declared inside the void function (void), all the variables are local variables, they are saved in the stack, when DSC jump out of the function (void), all the variables will be overwritten.

Pls have a try to declare all the variables as global variables by declaring them outside of the function (void).

for instance:

   UWord32 temp = 0;
  UWord32 temp0 = 0;
  UWord32 temp1 = 0;

void function (void) {
  temp1 = 2053;
  temp0 = (UWord32)(temp1 * 330);
  temp = temp0 >> 12;

...

}

Pls have a try.

BR

Xiangjun Rong

[dynapb]

Hi Sandro,

Do you have any math going on in your ISR's?

I have found out the math funcitons are not interrupt compatible (not reentrant I guess).

Don't recall exactly how I handled it but you can either have math in the interrupts or math in the background loop or both if you disable the interrupts before doing math in the background loop.

Pete