• AVR Freaks

AnsweredHot!32MZ Portpin issue, not consistent from time to time

Author
ThomasRhoon
Starting Member
  • Total Posts : 58
  • Reward points : 0
  • Joined: 2014/01/22 14:42:08
  • Location: 0
  • Status: offline
2020/06/26 06:43:21 (permalink)
0

32MZ Portpin issue, not consistent from time to time

Hello,
 
i just came against a rather weird issue that i can't explain. Using a circuit with a PIC32MZ2048EFH144 at 200Mhz. XC32 2.10 Pro.
I have a portpin which i use for a chip select that i reset for 1ms and set it again. That happens in an ISR (highest prio, Timer1) like every other millisecond. It works generally but after some time (seconds, milliseconds) randomly it seems that it doesn't reset, like it skips one. I can see that on the scope pictures, however, looking with an Logic Analyzer (with higher sample rate) i see that it indeed resets, but sets much too early again, after less than 2 microseconds).
 
This happens in an interrupt, where i toggle it basically (using a mini state machine).
I can reproduce that and there is no place in the code where this output is touched. (also no main port manipulation).
There is no difference if i use it like LATDbits.LATD5 or via LATDSET/LATDCLR.
 
The fun part comes, i placed another portpin toggle directly on the next line using LATBbits.LATBx and that one works as advertised. That shows me basically that there is no crazy stuff happening within the interrupt.
No difference with optimizations O0 -> O3 give the same results.
The pin itself is not used with any other periphery (PORTD5), leaving the pin loose without the CS connected doesn't make a difference either.

I attached a scope picture where you can see the result. On the bottom the CS pin which goes faulty and up there the portpin to compare. The pattern is correct, i do 4 times CS to sample and a slight pause to do again 4 samples. In the end you can see the CS pin is not reset while the other portpin is.
The other one is from the logic analyzer. Same situation, another time. There you can see also that the pin shortly resets but gets set again. (believing the analyser the CS time is 1670ns, the scope doesn't make that one visible)
 
Code:
State machine to Chip select in the ISR
LATDCLR = 0x20;       //LATDbits.LATD5 = 0
LATBbits.LATB12 = 0;
 
State machine to Chip deselect in the ISR another time (some Interrupts later)
LATDSET = 0x20;       //LATDbits.LATD5 = 1
LATBbits.LATB12 = 1;
 
Since the other pin (B12) works, i assume that the state machine works well.
I thought i was already deep with the micro and it's erratas for several years, but this is a strange behaviour i can't explain.
Anyone got a clue?
 
Thanks, Cheers

Attached Image(s)

#1
aschen0866
Super Member
  • Total Posts : 4574
  • Reward points : 0
  • Joined: 2006/01/08 22:18:32
  • Location: San Diego
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 07:12:58 (permalink) ☼ Best Answerby ThomasRhoon 2020/06/27 04:17:12
5 (1)
ThomasRhoon
There is no difference if i use it like LATDbits.LATD5 or via LATDSET/LATDCLR.
 

Make sure you use LATDSET/CLR/INV on ALL LATD pins. Also make sure you clear the T1 interrupt flag using the corresponding xxxxCLR register.
 
#2
ThomasRhoon
Starting Member
  • Total Posts : 58
  • Reward points : 0
  • Joined: 2014/01/22 14:42:08
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 07:33:04 (permalink)
0
aschen0866
ThomasRhoon
There is no difference if i use it like LATDbits.LATD5 or via LATDSET/LATDCLR.
 

Make sure you use LATDSET/CLR/INV on ALL LATD pins. Also make sure you clear the T1 interrupt flag using the corresponding xxxxCLR register.



Thanks, right i know and i do.  (IFS0CLR = 0x00000010;)
But that is not the issue here.
Setting through LATBbits is here just for illustration (and it even works well in my test, but not on the pin i need)
#3
LdB_ECM
Super Member
  • Total Posts : 409
  • Reward points : 0
  • Joined: 2019/04/16 22:01:25
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 08:20:38 (permalink)
0
You need to show the produced code of the interrupt including the prologue and epilogue of the interrupt.
If there is an error it's easy for it to mangle a specific bit on the register which translates to weird behaviour with port set/clear. As you already know beyond that has to be a silicon error.
post edited by LdB_ECM - 2020/06/26 08:21:54
#4
Stefiff
Senior Member
  • Total Posts : 99
  • Reward points : 0
  • Joined: 2012/07/15 15:26:29
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 13:35:27 (permalink)
0
If you change SOMETHING from port D, regardless of whether in the main program or in some interrupt, this will be the result.
There is a simple rule, if you change a port in an interrupt, then in all OTHER places, before you change the SAME port / ANY pin /, disable the interrupt. Enable it after the change. It does not matter where it is.
DI; change ANY D pin; EI;
DI – disable
EI - enable
 
This is used in a low priority ISR.
DI; change ANY D pin; RI;
RI - restore
#5
ThomasRhoon
Starting Member
  • Total Posts : 58
  • Reward points : 0
  • Joined: 2014/01/22 14:42:08
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 13:56:20 (permalink)
2 (1)
Stefiff
If you change SOMETHING from port D, regardless of whether in the main program or in some interrupt, this will be the result.
There is a simple rule, if you change a port in an interrupt, then in all OTHER places, before you change the SAME port / ANY pin /, disable the interrupt. Enable it after the change. It does not matter where it is.
DI; change ANY D pin; EI;
DI – disable
EI - enable
 
This is used in a low priority ISR.
DI; change ANY D pin; RI;
RI - restore


Hey thanks, but why is that? LATDSET/CLR/INV are atomic and i assume that a DI/EI is not necessary?
#6
Stefiff
Senior Member
  • Total Posts : 99
  • Reward points : 0
  • Joined: 2012/07/15 15:26:29
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 14:37:10 (permalink)
0
Unfortunately, my experience shows that you should, if you do not want to have problems. The processor executes the instructions on a 5-step pipeline, if I'm not mistaken. One instruction does not mean one clock. That's what experience has taught me.
There is also a complex way that is difficult to do. Distribute the ports, which will change where. ISR or outside of ISR.
#7
ThomasRhoon
Starting Member
  • Total Posts : 58
  • Reward points : 0
  • Joined: 2014/01/22 14:42:08
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 14:56:26 (permalink)
0
Stefiff
Unfortunately, my experience shows that you should, if you do not want to have problems. The processor executes the instructions on a 5-step pipeline, if I'm not mistaken. One instruction does not mean one clock. That's what experience has taught me.
There is also a complex way that is difficult to do. Distribute the ports, which will change where. ISR or outside of ISR.


Allright, lets see if the interrupt disabling solves the issue. I can't change the hardware anymore, so some PortD pins are served outside the ISR and one inside (i could move that outside as well probaby, but now i want to know).
I will provide the produced code if the problem is still there.
#8
aschen0866
Super Member
  • Total Posts : 4574
  • Reward points : 0
  • Joined: 2006/01/08 22:18:32
  • Location: San Diego
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 15:13:45 (permalink)
4 (1)
Stefiff
There is a simple rule, if you change a port in an interrupt, then in all OTHER places, before you change the SAME port / ANY pin /, disable the interrupt. Enable it after the change. 

That's nonsense. You need to better understand how CLR/SET/INV registers work.
#9
aschen0866
Super Member
  • Total Posts : 4574
  • Reward points : 0
  • Joined: 2006/01/08 22:18:32
  • Location: San Diego
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 15:18:52 (permalink)
0
ThomasRhoon
aschen0866
ThomasRhoon
There is no difference if i use it like LATDbits.LATD5 or via LATDSET/LATDCLR.
 

Make sure you use LATDSET/CLR/INV on ALL LATD pins. Also make sure you clear the T1 interrupt flag using the corresponding xxxxCLR register.



Thanks, right i know and i do.  (IFS0CLR = 0x00000010;)
But that is not the issue here.
Setting through LATBbits is here just for illustration (and it even works well in my test, but not on the pin i need)


Show us the code that sets up T1 interrupt and the T1 ISR itself.
#10
ric
Super Member
  • Total Posts : 28024
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/26 16:34:55 (permalink)
4 (1)
aschen0866
Stefiff
There is a simple rule, if you change a port in an interrupt, then in all OTHER places, before you change the SAME port / ANY pin /, disable the interrupt. Enable it after the change. 

That's nonsense. You need to better understand how CLR/SET/INV registers work.

+1.
This is only necessary if some other code is incorrectly using a PORTx register where it should use a LATX register.
 
Edit: aschen was 100% correct, as made plain in post#13.
Just using LATx is not enough, as setting bits in LATx is no atomic in the PIC32 architecture unless you use the Set/CLR/INV version.
post edited by ric - 2020/06/27 04:21:56

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#11
andersm
Super Member
  • Total Posts : 2834
  • Reward points : 0
  • Joined: 2012/10/07 14:57:44
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/27 00:24:06 (permalink)
0
Some PIC32M devices have the errata that an interrupted instruction can be executed twice, but the MZ EF family isn't affected.
#12
maxruben
Super Member
  • Total Posts : 3396
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/27 02:29:15 (permalink)
5 (2)
Make sure you use LATDSET/INV/CLR for all LATD bits, inside and outside interrupts.
 
/Ruben
#13
ThomasRhoon
Starting Member
  • Total Posts : 58
  • Reward points : 0
  • Joined: 2014/01/22 14:42:08
  • Location: 0
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/06/27 04:16:27 (permalink)
0
The problem is actually solved!
I manipulated another PIN of LATD through LATDbits in another low priority interrupt (hidden after a define, but my search skills overseen that for some reason, probably too focussed to one point. The project itself is quite big. 100k+ lines). So the chance that in the lower interrupt the LATDbits manipulation was interrupted by the higher prio interrupt happened. And because of the Read - Modify - Write nature of the LATDbits.LATDx usage, the port has been read (and modified) most probably, interrupted by the higher prio ISR, manipulating the PIN via LATDSET/CLR, but on release of the higher prio ISR, it came back to the write part of the lower ISR manipulation and so overwrote the former pin situation again.
That didn't happen to the other pin of course because it was on another not affected port.
 
So yes, LATxSET/INV/CLR for all LATx manipulations...and be sure to find also the buried ones :-)
 
Thanks for the help!
#14
moser
Super Member
  • Total Posts : 582
  • Reward points : 0
  • Joined: 2015/06/16 02:53:47
  • Location: Germany
  • Status: offline
Re: 32MZ Portpin issue, not consistent from time to time 2020/07/01 00:44:54 (permalink)
0
I was just reading through the thread for the first time, and from post #3 up to post #14 I had some urge to tell you exactly that:
Using LATxbits or LATxSET/INV/CLR is not the same, and makes a big difference, in particular if you use that outside of your interrupt/in a lower interrupt.
That is why almost everyone in this thead was pushing you to use SET/INV/CLR. You need understand how code like
LATxbits.LATxy = value_1_or_0;

actually works. It is more or less:
1) read the complete LATx register.
2) combine the read with the new value for bit y.
3) write back the complete LATx register with the result of that combination.
And this is usually bad! The issue with this is, that any change to LATx which happens between 1) and 3) gets lost, because in 3) you overwrite the change with the old state. And such changes can happen because of an interrupt.
 
#15
Jump to:
© 2020 APG vNext Commercial Version 4.5