Strange mplabx behaviour - reply Microchip
Locked
Strange mplabx behaviour - reply Microchip
 
|
Hello all...
As mentioned in my mail, I submitted the strange behaviour I experienced with mplab x to the Microchip bug list, and got as answer: <paraphrased> We believe that this is due to the read-modify-write nature of the bsf instructions. You should keep an image and update the image </paraphrased> (...and closed the bug) If I understand the RMW behaviour, then the possible problems are due to either capacitive (or other) loading of the outputs, or having some internal peripheral enabled which could cause the same loading. Is there any way this could explain my problem? I even tried the 'image' method to update port A, and the mplab X simulator _still_ doesn't show any change to the port A output. Am I really that far off my game? Could someone try to run this code and check if they have the same problems? (MPLAB X is Linux 64bit version 1.30 here) Gpsim and the actual hardware say I'm right... John BSF Code: processor pic16f874 include P16F874.INC org 0 goto start org 4 start banksel TRISA movlw b'00000111' movwf ADCON1 movlw b'00111001' movwf TRISA clrf TRISB banksel PORTA loop bsf PORTA,1 bsf PORTA,2 bcf PORTA,1 bcf PORTA,2 goto loop end Direct modification code (no RMW): --------------------------- processor pic16f874 include P16F874.INC org 0 goto start org 4 start banksel TRISA movlw b'00000111' movwf ADCON1 movlw b'00111001' ; Bits 1 & 2 as outputs movwf TRISA clrf TRISB banksel PORTA loop movlw 2 movwf PORTA movlw 6 movwf PORTA movlw 4 movwf PORTA movlw 0 movwf PORTA goto loop end -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
John Coppens wrote 2012-08-24 21:17: > Hello all... > > As mentioned in my mail, I submitted the strange behaviour I > experienced with mplab x to the Microchip bug list, and got as answer: > > <paraphrased> > We believe that this is due to the read-modify-write > nature of the bsf instructions. You should keep an image and update the > image > </paraphrased> (...and closed the bug) > > If I understand the RMW behaviour, then the possible problems are due > to either capacitive (or other) loading of the outputs, or having some > internal peripheral enabled which could cause the same loading. > > Is there any way this could explain my problem? I even tried the > 'image' method to update port A, and the mplab X simulator _still_ > doesn't show any change to the port A output. > Now, Note that the RWM problem *never* hits the *same pin* as your are BCF/BSF'ing !! The RWM problem will show up as random changes of *other* pins then the one you are targeting with your BCF/BSF. Usualy another pin changed with a BCF/BSF directly before the other BCF/BSF. That is when the RMW might reset the first pin since it hadn't had time to get to a stable level on the pin. Now, it you are BSF'ing a pin that is configured as an analog input, it *should* show as "0" in the simulator because that is how the hardware sees it. But *that* is *not* a RWM issue ! It's absolutely normal. :-) Have you given them a reproducer? That is, actual code that shows the problem? Jan-Erik. > Am I really that far off my game? Could someone try to run this code and check > if they have the same problems? (MPLAB X is Linux 64bit version 1.30 here) > Gpsim and the actual hardware say I'm right... > > John > > BSF Code: > processor pic16f874 > include P16F874.INC > > org 0 > > goto start > > org 4 > > start > banksel TRISA > movlw b'00000111' > movwf ADCON1 > > movlw b'00111001' > movwf TRISA > > clrf TRISB > > banksel PORTA > loop > bsf PORTA,1 > bsf PORTA,2 > > bcf PORTA,1 > bcf PORTA,2 > goto loop > > end > > Direct modification code (no RMW): --------------------------- > > processor pic16f874 > include P16F874.INC > > org 0 > > goto start > > org 4 > > start > banksel TRISA > movlw b'00000111' > movwf ADCON1 > > movlw b'00111001' ; Bits 1 & 2 as outputs > movwf TRISA > > clrf TRISB > > banksel PORTA > loop > movlw 2 > movwf PORTA > movlw 6 > movwf PORTA > movlw 4 > movwf PORTA > movlw 0 > movwf PORTA > > goto loop > > end > http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
Without looking at the particular problem, I will say that a dead giveaway
to an R/M/W problem is that the same code works properly when you single-step it. You can guess how I know this. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
RE: Strange mplabx behaviour - reply Microchip
|
|
In reply to this post by John Coppens
John Coppens wrote:
> > Hello all... > > As mentioned in my mail, I submitted the strange behaviour I > experienced with mplab x to the Microchip bug list, and got as answer: > > <paraphrased> > We believe that this is due to the read-modify-write nature of the bsf > instructions. You should keep an image and update the image > </paraphrased> (...and closed the bug) > > If I understand the RMW behaviour, then the possible problems are due > to either capacitive (or other) loading of the outputs, or having some > internal peripheral enabled which could cause the same loading. > > Is there any way this could explain my problem? I even tried the > 'image' method to update port A, and the mplab X simulator _still_ > doesn't show any change to the port A output. Microchip's reply sounds like a cop-out to me. RMW potentially affects actual hardware, in ways that depend on the hardware. A simulator can't take that into account (ok, unless you're using something like Proteus with a SPICE model of the attached hardware). RMW should not be the explanation for what you see in the simulator. I suspect that Microchip didn't understand what you were getting at (or didn't take the time to understand...). Cheers, David Meiklejohn www.gooligum.com.au -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
Actually, it would not be a big deal to detect RMW errors on the emulator -
it is just checking when the last write happened to the actual port, and if X virtual time tick passed, then it is safe again to read that port, otherwise log it as RMW error on the console. You may even can control this by the simulator settings, so one can increase this minimum tick value for deeper test (sometimes a nop is inserted in between RMW instructions as a quick fix and that might not enough in some case, so you can go even further). For this kind of dummy tests you do not need a real SPICE simulation... Tamas On 24 August 2012 15:36, David Meiklejohn <[hidden email]> wrote: > John Coppens wrote: > > > > Hello all... > > > > As mentioned in my mail, I submitted the strange behaviour I > > experienced with mplab x to the Microchip bug list, and got as answer: > > > > <paraphrased> > > We believe that this is due to the read-modify-write nature of the bsf > > instructions. You should keep an image and update the image > > </paraphrased> (...and closed the bug) > > > > If I understand the RMW behaviour, then the possible problems are due > > to either capacitive (or other) loading of the outputs, or having some > > internal peripheral enabled which could cause the same loading. > > > > Is there any way this could explain my problem? I even tried the > > 'image' method to update port A, and the mplab X simulator _still_ > > doesn't show any change to the port A output. > > Microchip's reply sounds like a cop-out to me. RMW potentially affects > actual hardware, in ways that depend on the hardware. A simulator can't > take that into account (ok, unless you're using something like Proteus with > a SPICE model of the attached hardware). RMW should not be the explanation > for what you see in the simulator. > > I suspect that Microchip didn't understand what you were getting at (or > didn't take the time to understand...). > > > Cheers, > David Meiklejohn > www.gooligum.com.au > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q; printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }", q="\"",s,q,q,a="\\",q,q,q,a,a,q); } -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
There are three possible causes of RMW issues that may affect PICs:
a) Due to capacitive loading: One instruction modifies a pin then another instruction reads the pin value and writes it back as a side effect of modifying another pin in the same port. Because of the capacitive loading, the first pin didn't have time to settle to the value set by the first instruction before the second instruction samples its value. Ex.: clrf PORTA . . ; some delay... . bsf PORTA,0 bsf PORTA,1 The 'bsf' instruction reads the entire port, modifies one bit and then writes the entire port back. The first 'bsf' reads the already stable value of PORTA and sets its bit 0. The second 'bsf' reads again the value of PORTA. The bit 0 voltage is raising but didn't reach the level '1' threshold, so it is read still as '0'. Then the instruction writes bit 0 as '0' and bit 1 as '1'. b) Due to a pin being input then changed to output: movlw 0x03 movwf PORTA ; here all bits of the latch of PORTA are initialized to a known value, even the ones that are inputs, because movwf doesn't have issues with RMW. banksel TRISA clrf TRISA ; bits 0 and 1 change to '1' correctly . . . bsf TRISA,1 ; bit 1 is changed to input. Here we assume that it is pulled down externally banksel PORTA bcf PORTA,0 ; we clear bit 0, that is still an output, and it works OK, but bit 1 is read also and as it is an input and pulled low externally, the value written back for bit 1 is '0' banksel TRISA bcf TRISA,1 ; change bit 1 back to output. Some would assume that it would output an '1', but due to RMW it will be a '0'. c) Due to a pin being an output but configured as analog: ; RA0 is configured as output but also as analog and RA1 is a digital output bsf PORTA,0 ; RA0 changes to '1' . . . ; some delay to avoid capacitive RMW . bsf PORTA,1 ; RA1 changes to '1', but RA0 changes to '0' because when the instruction reads the port value, RA0 is read as '0' because as it is configured as analog its digital input circuitry is turned off. Best regards, Isaac Em 24/8/2012 19:48, Tamas Rudnai escreveu: > Actually, it would not be a big deal to detect RMW errors on the emulator - > it is just checking when the last write happened to the actual port, and if > X virtual time tick passed, then it is safe again to read that port, > otherwise log it as RMW error on the console. You may even can control this > by the simulator settings, so one can increase this minimum tick value for > deeper test (sometimes a nop is inserted in between RMW instructions as a > quick fix and that might not enough in some case, so you can go even > further). For this kind of dummy tests you do not need a real SPICE > simulation... > > Tamas > > > On 24 August 2012 15:36, David Meiklejohn <[hidden email]> wrote: > >> John Coppens wrote: >>> Hello all... >>> >>> As mentioned in my mail, I submitted the strange behaviour I >>> experienced with mplab x to the Microchip bug list, and got as answer: >>> >>> <paraphrased> >>> We believe that this is due to the read-modify-write nature of the bsf >>> instructions. You should keep an image and update the image >>> </paraphrased> (...and closed the bug) >>> >>> If I understand the RMW behaviour, then the possible problems are due >>> to either capacitive (or other) loading of the outputs, or having some >>> internal peripheral enabled which could cause the same loading. >>> >>> Is there any way this could explain my problem? I even tried the >>> 'image' method to update port A, and the mplab X simulator _still_ >>> doesn't show any change to the port A output. >> Microchip's reply sounds like a cop-out to me. RMW potentially affects >> actual hardware, in ways that depend on the hardware. A simulator can't >> take that into account (ok, unless you're using something like Proteus with >> a SPICE model of the attached hardware). RMW should not be the explanation >> for what you see in the simulator. >> >> I suspect that Microchip didn't understand what you were getting at (or >> didn't take the time to understand...). >> >> >> Cheers, >> David Meiklejohn >> www.gooligum.com.au >> >> >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
While thinking about the sequence for an R/M/W error, it occurred to me
that a write (an output change) immediately precedes the R/M/W instruction. So, maybe it should be called W+R/M/W, since that's what's actually happening. Per Issac's message, changing a TRIS bit to cause an input to become an output is really another way of writing to a port pin. And causes the same trouble if an RMW instruction happens too soon thereafter. The third example (analog configuration) should be able to be mimicked by the simulator. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
In reply to this post by David Meiklejohn
> I suspect that Microchip didn't understand what you were > getting at (or didn't take the time to understand...) I hesitate to contact Microchip Support for that very reason The last time time I pointed out what eventually was discovered to be a real silicon fault, I was fobbed off for weeks with bland answers to irrelevant questions I didn't ask, with no attempt to actually replicate the fault scenario I described. The problem was with a dsPIC and yet the reply was "It works on the 24F I tried". Absolutely pointless It resulted in me sending a letter to the Support Training manager at corporate HQ It wasn't the first time they just didn't try and appear to be confined to some sort of inflexible checklist. You can tell - "Is the chip in the right way, what's Vdd, are you sure you've set such-and-such" etc. The impression I always get is that they are simply front-office seat-warmers I'm wondering whether these support people are any good at programming or really know the chips. More than once I've been instructed to do something which has already clearly been done in the snippets I send Joe -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
On 24 August 2012 17:17, IVP <[hidden email]> wrote:
> The last time time I pointed out what eventually was discovered > to be a real silicon fault, I was fobbed off for weeks with bland > answers to irrelevant questions I didn't ask, with no attempt to > actually replicate the fault scenario I described. The problem > was with a dsPIC and yet the reply was "It works on the 24F > I tried". Absolutely pointless > I have not tried this with Microchip yet, but usually this magic phrase works in all customer care or technical support services: "I would like to escalate this problem". "Escalation" is somehow a magic word in modern aftermarket services and it immediately goes to the manager or a higher level stuff who usually understands what you are saying or meaning -- they pay more for these people and they are trained well usually. Last time I used this "sorcery" was a month ago with Apple, where I realized my questions never got real attention -- after I expressed this word I ended up talking to senior advisers and did save a huge amount of time and they did actually care about my issue afterwards. Tamas -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
> usually this magic phrase works in all customer care or
> technical support services: "I would like to escalate this > problem" Thanks, I'll remember that Don't get me wrong - the support staff are probably ordinary decent people, but they really seem to have been trained only up to a certain level and I appreciate that they must receive a veritable mountain of bunny questions with easy answers. I would just like them to realise that occassionally they will face a question that needs technical beyond their training and pass it on a bit quicker Joe -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
On 24 August 2012 17:54, IVP <[hidden email]> wrote:
> I would just like them to realise that occassionally they will face > a question that needs technical beyond their training and pass > it on a bit quicker > As far as I know they are forced to do the numbers (how many customers they handle per day, and how many was escalated etc which they have to keep to a minimum of course). So I can understand this, although it does not really help us sometimes. Tamas > > Joe > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q; printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }", q="\"",s,q,q,a="\\",q,q,q,a,a,q); } -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
In reply to this post by Jan-Erik Söderholm
On Fri, 24 Aug 2012 21:46:42 +0200
Jan-Erik Soderholm <[hidden email]> wrote: > Now, Note that the RWM problem *never* hits the *same pin* as > your are BCF/BSF'ing !! > > The RWM problem will show up as random changes of *other* pins > then the one you are targeting with your BCF/BSF. Usualy another > pin changed with a BCF/BSF directly before the other BCF/BSF. > That is when the RMW might reset the first pin since it hadn't > had time to get to a stable level on the pin. Hi Jan.Erik... Yes... I am (old) electronics engineer, so I really understand the mechanics of the RMW problem. After 35-odd years with various microprocessors, I've had my share of (even stranger) problems! > Now, it you are BSF'ing a pin that is configured as an > analog input, it *should* show as "0" in the simulator > because that is how the hardware sees it. But *that* > is *not* a RWM issue ! It's absolutely normal. :-) Yep... But the A/D _was_ switched off. > Have you given them a reproducer? > That is, actual code that shows the problem? I sent them the code, and I even sent them a screen grab showing actual single stepping through the execution and showing the results. I tried to re-open the issue, but didn't find how. So I re-submitted the report. John -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
In reply to this post by David Meiklejohn
On Sat, 25 Aug 2012 08:36:22 +1000
"David Meiklejohn" <[hidden email]> wrote: > Microchip's reply sounds like a cop-out to me. RMW potentially affects > actual hardware, in ways that depend on the hardware. A simulator can't > take that into account (ok, unless you're using something like Proteus with > a SPICE model of the attached hardware). RMW should not be the explanation > for what you see in the simulator. > > I suspect that Microchip didn't understand what you were getting at (or > didn't take the time to understand...). Or, maybe, they took my mentioning 'simulator' as being the in-circuit emulator or -debugger. Though English is not my native language, I believe the bug report was clear enough. I can believe they're somewhat stressed. In one week, the ticket number went up by 350! That's about 70 tickets per working day. Anyway, #235011 is the new ticket. John -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
In reply to this post by Barry Gershenfeld-2
Barry Gershenfeld wrote 2012-08-25 02:14: > While thinking about the sequence for an R/M/W error, it occurred to me > that a write (an output change) immediately precedes the R/M/W > instruction. So, maybe it should be called W+R/M/W, since that's what's > actually happening. > > Per Issac's message, changing a TRIS bit to cause an input to become an > output is really another way of writing to a port pin. And causes the same > trouble if an RMW instruction happens too soon thereafter. > > The third example (analog configuration) should be able to be mimicked by > the simulator. I have never seen MPLAB/MPSIM missing the last case (analog pin), which is the most simple one, of course. That is a well documented behavour. I'm not sure of the the middle case (writing to an digital-input pin). When reading from an input pin (without a stimulus setup) the value is "undefined", I guess. The first case (capactive loading) is hard (if not impossible) to simulate using something like MPSIM. Jan-Erik. > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
On 25 August 2012 02:40, Jan-Erik Soderholm <[hidden email]>wrote:
> The first case (capactive loading) is hard (if not impossible) > to simulate using something like MPSIM. > I have to disagree with that, already explained that a simple time stamp on the port would do that for you. So you store the actual time tick when the port was written, then next time you do an RMW instruction it checks if at least 4 ticks (or any other configurable value) passed since. Knowing the simulated fosc frequency you may even could setup the constrain of simulated time instead of the ticks. Also a compiler could detect RMW instructions right after each others and display a warning, that's not a rocket science either. With this latter one maybe Microchip could provide a kind of static analysis tool such as lint or splint, which would help us detecting obvious mistakes or bogus code... http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis Tamas > > Jan-Erik. > > > > > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q; printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }", q="\"",s,q,q,a="\\",q,q,q,a,a,q); } -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: Strange mplabx behaviour - reply Microchip
|
|
In reply to this post by John Coppens
On Sat, 25 Aug 2012 01:37:36 -0300
John Coppens <[hidden email]> wrote: > Anyway, #235011 is the new ticket. In order not to maintain the suspense, I got a reply from the bug report yesterday, in which the (same) tech apologizes, and confirms having sent the report to the development people. Let's see if anything comes from it. He did indicate that the GPSIM from MPLAB X is beta, and as such not too reliable. And that I shouldn't use the f874 (too old) ;-) Greetings, John -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
«
Return to PIC - [PIC]
|
1 view|%1 views
| Free forum by Nabble | Edit this page |