• AVR Freaks

Hot!Issue with entire dsPIC33Cx family with byte mode instructions? - resolved

Page: < 1234 > Showing page 2 of 4
Author
Gort2015
Klaatu Barada Nikto
  • Total Posts : 3121
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/14 06:33:19 (permalink)
1 (2)
This is all bullshit from the OP about the upper byte.
Typical newbie code.
 

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#21
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/14 13:47:26 (permalink)
5 (8)
Your posts frequently display your arrogant attitude, and frankly I am tired of seeing it as are others who have contacted me privately about this issue.  If you can't provide positive input I would recommend that you not participate in discussions instead of making assumptions.  I am certainly no newbie.  I have been using PIC's since they were only available as UV erasable parts.  I have released more than 300 commercial products using PIC micros, using literally millions of PIC parts.  My information comes directly from Microchip support, and the problem is VERY real.  Here is the latest info I received today which defines the condition as they currently know it:
 
[code]
Created By: Matthew Robertson (3/14/2019 12:53 PM)
Hello Jim,

I got some information for you regarding the errata. There is a bit that still needs to be confirmed, but so far this is what I have.
====
The errata regarding byte mode instructions only applies to the specific scenario where the source and destination registers are the same and there is a specific "write after read" hazard.

The example that you provided is not expected to be affected since the pointer update [W2++] is a different register than the instruction destination register W0. This doesn't comment on the rest of your cases though.

In the example given to us by our design team, indirect addressing and byte mode instructions are used at the same time with the same source and destination registers. The usage model for this may be limited.

////////////////////////////////////////////////////
Instruction: INC2.b [W12++], W12

Value in W12 = 0x74ff

Value in 0x74ff = 0xf321

Since we are incrementing the value in 0x74ff (0xf3) by 2, we except that the W12[7:0] = 0xf5. This is as expected.

But the value in W12[15:8] is incorrect.

Since this is a byte mode instruction, W12 (viewing it as an address) should increment by 1.

So, W12 = 0x74ff+0x1 = 0x7500

Now, because of the operation of this instruction, W12[7:0] is 0xf5.

Because of the address generation unit, W12[15:8] = 0x75

So the expected value of W12 should be 0x75f5.

However, the data write back takes priority over the address write back and we see W12 = 0x74f5.

////////////////////////////////////

I am currently waiting on more feedback from the design team regarding the exact errata language we should update to to make this clearer for the future, but I wanted to clarify that this is not a marginal timing issue. This is a functional difference from the reference model on how to handle this specific hazard, data write back vs address increment write back to the same register.
In other words, code that shows the issue should always show the issue and code that does not show the issue should never show the issue.

We are continuing to collect more information for you, and I will let you know when I hear back. Please let me know if you have further questions.

Thank you,

Matthew

 
 
 
 
 
#22
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/14 13:57:21 (permalink)
4.5 (2)
I can confirm that with the dsPIC33CH512MP206 that the example Matthew gave me results in the issue.  I am going to try other RMW cases where the same registers are being used.
 
#23
JPortici
Super Member
  • Total Posts : 674
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 00:08:27 (permalink)
5 (2)
RANT:
I don't understand why they didn't write THAT in the errata in the first place.
Maybe because they are not sure it's limited to this scenario?
 
But still, i hate cryptic erratas with passion, they make me want to skip on this controller and redesign on something else.
 
At least, it's reassuring that the behaviour doesn't come up erratically
post edited by JPortici - 2019/03/15 00:09:51
#24
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 03:20:30 (permalink)
5 (1)
I agree, I'd consider this to be very much an edge case, and it would have been a lot more useful to communicate that. I can't imagine writing code like this myself, where there's an auto increment or decrement on the same register I'm writing to, but that's not to say there might be some "clever" compiler shenanigans.
 
Is there even defined behaviour for this situation?
 
(Edit: also confirmed on dsPIC33CH128MP508 on a Curiosity board, although I had to use address 0x34FF as 0x74FF isn't in this processor's memory map).
post edited by Howard Long - 2019/03/15 03:24:21
#25
NorthGuy
Super Member
  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 05:53:33 (permalink)
0
If it was a word instruction:
 
inc2.w [w12++],w12

 
then ++ would be ignored and overwritten with data. Therefore there's no reason to use "++" in the first place, and it gets ignored.
 
They ignore it with byte operation too. They consider this as a bug, but it looks totally normal to me. It is very simple to document as a CPU feature, rather than issuing an errata saying that all byte operations are incorrect (why not to blame all auto-increments?).
 
I wonder if this has always been there, or it's something new for Cx series?
 
I reminds me of C. If you write:
 
x = a[x++];

 
you don't blame the compiler for the results. This explains why the used letter "C" to name this family.
#26
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 08:40:56 (permalink)
0
NorthGuy
I wonder if this has always been there, or it's something new for Cx series?

 
I just tried it on a PIC24FV16KM202, it does the same thing, the high byte is trashed on the destination.
 

 
uint16_t * const pu16=(uint16_t *)0x0CFE;

*pu16=0xF321;

WREG12=0x0CFF;
__asm( "inc2.b [w12],w12" ); // OK, high byte is persisted
WREG12=0x0CFF;
__asm( "inc2.b [w12++],w12" ); // Trashes what would be high byte if it were a word rather than a byte increment
 

 
Edit: the simulator "works", both on the dsPIC33CH and the PIC24 I tried. Although again, I am unsure as to where you'd ever encounter this specific scenario in the real world.
post edited by Howard Long - 2019/03/15 09:03:05
#27
du00000001
Just Some Member
  • Total Posts : 2677
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 09:07:27 (permalink)
0
To be honest:
IMHO, applying 2 concurring operations on the very same register seems to be of little use.
I cannot really imagine an application where the critical case would make sense (aka "create a significant advantage if flawless") if implemented correctly.
Otherwise this is more or less academical...

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#28
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 12:12:26 (permalink)
0
I can see where this issue could cause a problem in real-world code.  For example, if you do an indirect fetch from memory to the same register (i.e. mov.b [w0++],w0) and then modify (add/subtract) from the upper byte as a table offset for a jump table (that then uses GOTO or BRA).  When crossing a page boundary this bug would prevent that from working.  I have done table to table lookups similar to this in the past.  It's an effective way to do microcode decoding.  I will just keep in mind that different registers should be used.  I am waiting to find out still if this is the only case that was found.  Fortunately, the big scare message that I got originally from Microchip of "don't use any byte operations and expect the upper byte to remain the same" was them being overly cautious!  I will drop Microchip a note about the FV part having the same issue.
 
#29
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 14:18:34 (permalink)
0
JimDrew
I will drop Microchip a note about the FV part having the same issue. 


The FV part just happened to be with me at the time, I was out in the field today. I woudn’t be at all surprised if it affects all dsPIC and PIC24 as NorthGuy alluded to.
#30
JPortici
Super Member
  • Total Posts : 674
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/15 17:51:25 (permalink)
0
At this point, if it really affects ALL dsPIC/PIC24 it would be interesting to know why they just found about it now... what were they testing
#31
Stampede
Super Member
  • Total Posts : 391
  • Reward points : 0
  • Joined: 2006/10/04 05:59:28
  • Location: Germany
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/16 03:48:37 (permalink)
0
MBedder
Stampede...keeping in mind that the dspic33EP e.g. uses the same core
No. The Cx core(s) are completely different. And all the Cx are too new to make a practical use of them.



After having found that bug in other controllers, maybe I wasn't wrong. Question really is why they didn't find that bug earlier....
#32
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/16 08:22:59 (permalink)
0
Stampede
MBedder
Stampede...keeping in mind that the dspic33EP e.g. uses the same core
No. The Cx core(s) are completely different. And all the Cx are too new to make a practical use of them.


After having found that bug in other controllers, maybe I wasn't wrong. Question really is why they didn't find that bug earlier....


Perhaps the side effects are different?

Also, I’d prefer it that others confirm or refute my understanding of the problem, both in terms of the axioms of reproducibilty, and scope across the 16 bit family

Right now, I take it to be an extreme and contrived edge case where the result is not defined for any of the 16 bit processors.

If someone has really written some code that uses, or takes advantage, of this “feature”, then, given the details we have now, may I suggest they shouldn’t have done.

As Jportico suggested, the errata statement has turned out to be more of a FUD than giving any practical use. I’d love to have been in the management meeting where they decided to release that.

While there may be more detail to come, at present this would barely make a datasheet clarification, let alone an errata.
post edited by Howard Long - 2019/03/16 08:37:13
#33
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/16 08:22:59 (permalink)
0
Dupe, apologies.
post edited by Howard Long - 2019/03/16 08:32:25
#34
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/16 12:54:48 (permalink)
0
If someone has really written some code that uses, or takes advantage, of this “feature”, then, given the details we have now, may I suggest they shouldn’t have done.

 
It's probably more of a case where the code didn't work because of the bug (not a feature).
 
mov.b [w0++],w0   ; get byte from table
lsr w0,#8,w1  ; get upper byte of table address    <--- failure occurs here
add w1,w2,w1  ; add table offset for next decode sequence
add.b w1,w0,w1  ; add offset from table
bra w1
 
This would fail if the original value in w0 crosses a page boundary.  I am sure there are some other real-world cases that could exist.  I am just hoping that this is in fact the only issue they have found.
 
 
#35
NorthGuy
Super Member
  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/16 14:05:57 (permalink)
0
JimDrew
mov.b [w0++],w0   ; get byte from table
lsr w0,#8,w1  ; get upper byte of table address    <--- failure occurs here
add w1,w2,w1  ; add table offset for next decode sequence
add.b w1,w0,w1  ; add offset from table
bra w1



This gibberish could never be a part of a useful program. You need to work much harder to produce an example of code which may do something useful and is affected by the bug. Nothing surprising that no one have found it for years.
 
#36
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/17 13:26:58 (permalink)
0
That's not gibberish.  :)  That is a method of doing microcode lookup through a series of tables when emulating a CPU core.  I do something very similar (which is how I know about this example), but I don't use the same register for the table fetch because I might need it later for another possible fetch (depending on the opcode).  Tables are setup for handling instruction decoding based on their group attributes.  It's better having several sets of 256 word lookup tables than a giant 64K word lookup table.  This is for a 680x0 CPU emulation.
 
I agree... if this issue affects all of the various 16 bit PICs, it is surprising it has not already been found.
 
I am wondering though if Microchip found it themselves when they released the latest version of the XC16 compiler that was mysteriously pulled, and then replaced with the "'b" version.  Maybe the new compiler was "optimized" and this bug showed its ugly face.  :)
 
I am hoping to get some final closure on this when Microchip tells me that this is the only issue.
 
post edited by JimDrew - 2019/03/17 21:29:49
#37
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/18 02:28:49 (permalink)
0
FWIW, a straw poll of some other parts I happen to have with me today shows the same feature existing on PIC24FJ256GA702, PIC24F16KL402 and PIC24F32KA302.
#38
Howard Long
Super Member
  • Total Posts : 672
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/18 02:32:35 (permalink)
0
Regarding the gibberish question, what is the point of a post increment here, and why would you ever do it at all? If you don't use the post increment, the high byte is unaffected.
 
mov.b [w0++],w0   ; get byte from table
lsr w0,#8,w1  ; get upper byte of table address    <--- failure occurs here
add w1,w2,w1  ; add table offset for next decode sequence
add.b w1,w0,w1  ; add offset from table
bra w1
 
#39
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/18 17:27:31 (permalink)
0
....
post edited by JimDrew - 2019/03/18 19:10:08
#40
Page: < 1234 > Showing page 2 of 4
Jump to:
© 2019 APG vNext Commercial Version 4.5