• AVR Freaks

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

Page: < 1234 Showing page 4 of 4
Author
NorthGuy
Super Member
  • Total Posts : 5379
  • 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/21 21:33:29 (permalink)
0
JimDrew
I think maybe the issue here really is that everything (programmers and compilers) has expected the high byte to always be 0x00 (like what the ZE instruction does)



It certainly has nothing to do with programmers.
 
As to the compilers, I would bet you won't be able to create a C code which would produce "mov.b [wx++],wx" instruction with XC16 compilers.
#61
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: online
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/21 22:03:54 (permalink)
0
without using inline asm ;)
 

Only 5 to go...
#62
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/22 00:46:09 (permalink)
5 (1)
I think forum needs an errata!
 
post edited by JimDrew - 2019/03/22 00:48:31
#63
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/22 00:49:43 (permalink)
5 (2)
The final word has come from Microchip today:
 
Created By: Matthew Robertson (3/21/2019 1:47 PM)
Hello Jim,

I'll pass your comments off to my colleague and see what he says, but in the meantime, I have received clarification on the issue.

Here is the most recent issue description.

"When using byte mode instructions with modified indirect addressing and the same source and destination register, the data write back will have priority over the address write back.

For example, any instruction using the format "xxx.b [Wy++], Wy" would exhibit this behavior. The actual byte mode instruction used does not matter.

It is recommended that when using byte mode instructions with modified indirect addressing, avoid using the same source and destination address."

Regarding which devices are affected, all dsPIC/PIC24 will block the modified indirect address update. The newer CH/CK devices will block any data write back from overflowing into the upper byte.

To be clear, we believe there is no valid usage model for mixing a 16 bit address and byte data in the same working register.  In addition, our C compiler does not generate code that would be affected by this issue.

None of the code examples you provided would be affected. As long as you verify that the above condition does not occur somewhere else in your code, you should be good. I apologize for the confusion over this issue.

If you have further questions, just let me know, and I will get back to you as soon as I can. Otherwise, if you no longer need further engagement, feel free to close the case.

Thank you,

Matthew
 
 
So the good news is that this is the complete description of the issue, which should have been included in the errata in the first place.  This issue will never affect me, or likely anyone else.  I can happily continue on to production!
 
 
#64
JPortici
Super Member
  • Total Posts : 668
  • 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/22 01:48:27 (permalink)
0
This should be added to the programmer's manual as well!
#65
Howard Long
Super Member
  • Total Posts : 664
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: online
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/22 04:54:00 (permalink)
0
I realise that this is now largely an academic exercise, but can someone provide example code that behaves differently on the newer CH/CK devices to earlier 16 bit devices? Either I haven't understood the problem, or the result is indeed the same, in that the upper byte is always zeroed as far as I can see, whether or not it's a newer CH/CK device. This includes the Microchip example given on page two of the thread.
#66
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/22 12:12:09 (permalink)
0
Yeah, this is odd.  Clearly Microchip identifies the issue as being different between the PIC24/dsPIC and new CK/CH parts.  I have only seen this to be true with one part (dsPIC33CH512MP208).  Ironically, that is the part that I was referencing when I asked for clarification on this matter.  I was going through the errata as part of the verification process for DO-178C compliantcy and noticed the passage about the byte mode operations affecting the upper byte in a word - which opened this can of worms. 
 
 
 
 
#67
Howard Long
Super Member
  • Total Posts : 664
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: online
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/22 13:05:50 (permalink)
0
I just soldered up a dsPIC33CH512MP208, and I can only reproduce the zeroed high byte, the same as before.
 

#pragma config FNOSC = FRC // Oscillator Source Selection (Internal Fast RC (FRC))
#pragma config IESO = OFF // Two-speed Oscillator Start-up Enable bit (Start up with user-selected oscillator source)
#pragma config POSCMD = NONE // Primary Oscillator Mode Select bits (Primary Oscillator disabled)
#pragma config OSCIOFNC = OFF // OSC2 Pin Function bit (OSC2 is clock output)
#pragma config FCKSM = CSECMD // Clock Switching Mode bits (Clock switching is enabled,Fail-safe Clock Monitor is disabled)
#pragma config PLLKEN = PLLKEN_OFF // PLLKEN (PLLKEN_OFF)
#pragma config WINDIS = OFF // Watchdog Timer Window Enable bit (Watchdog Timer operates in Window mode)
#pragma config FWDTEN = ON_SW // Watchdog Timer Enable bit (WDT controlled via SW, use WDTCON.ON bit)
#pragma config ICS = PGD1 // ICD Communication Channel Select bits (Communicate on PGC1 and PGD1)
#pragma config JTAGEN = OFF // JTAG Enable bit (JTAG is disabled)

#include <xc.h>

int main(void)
{
*(uint16_t *)0x1234=0xAA55;
*(uint16_t *)0x12FE=0xAA55;
*(uint16_t *)0x74FE=0xF321;
// ________________________________ Hardware / Simulator
// Post-increment examples
__asm("mov #0x1234,w0"); // w0 = 0x1234 / 0x1234
__asm("mov.b [w0++],w0"); // w0 = 0x0055 / 0x1255 ****
__asm("mov #0x12FF,w0"); // w0 = 0x12FF / 0x12FF
__asm("mov.b [w0++],w0"); // w0 = 0x00AA / 0x13AA ****
// Pre inc/dec examples
__asm("mov #0x1234,w0"); // w0 = 0x1234 / 0x1234
__asm("mov.b [++w0],w0"); // w0 = 0x00AA / 0x12AA ****
__asm("mov #0x1300,w0"); // w0 = 0x1300 / 0x1300
__asm("mov.b [--w0],w0"); // w0 = 0x00AA / 0x12AA ****
// Microchip example
__asm("mov #0x74FF,w12"); // w12 = 0x74FF / 0x74FF
__asm("inc2.b [w12++],w12"); // w12 = 0x00F5 / 0x75F5 ****
while (1)
{
Nop();
}
return 0;
}

Attached Image(s)

#68
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/22 16:01:12 (permalink)
0
My chip is a later production run than yours (16 weeks) and has a different mask code.
 
Your date code/ID: 1833KRD
My date code/ID: 1849OR7
 
 

Attached Image(s)

#69
Howard Long
Super Member
  • Total Posts : 664
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: online
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/26 07:40:48 (permalink)
0
Could you kindly share your code that reproduces the problem?
 
Many thanks, Howard
#70
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/29 13:31:12 (permalink)
0
Sure...
 
mov #0x12FF,w0
mov.b [w0++],w0
 
..it's the same code that I have been using in all of my examples.
 
The result is 0x12 in the upper byte (with the dsPIC512MP208, not 0x00 like with my other CH PICs) and whatever 0x12FF was pointing to in the lower byte.
 
 
#71
Howard Long
Super Member
  • Total Posts : 664
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: online
Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/04/23 13:58:31 (permalink)
0
Hello JimDrew
 
Sorry, I've only just come back to this.
 
I tested this on
 
o dsPIC33CH512MP508 PIM on an Explorer 16/32 board
o dsPIC33CH128MP508 on an dsPIC33CH Curiosity board
 
And both end up with 00 in the high byte of W0.
 
I used identical source code for each test, shown below.
 

#pragma config FNOSC = FRC // Oscillator Source Selection (Internal Fast RC (FRC))
#pragma config IESO = OFF // Two-speed Oscillator Start-up Enable bit (Start up with user-selected oscillator source)
#pragma config POSCMD = NONE // Primary Oscillator Mode Select bits (Primary Oscillator disabled)
#pragma config OSCIOFNC = OFF // OSC2 Pin Function bit (OSC2 is clock output)
#pragma config FCKSM = CSECMD // Clock Switching Mode bits (Clock switching is enabled,Fail-safe Clock Monitor is disabled)
#pragma config PLLKEN = PLLKEN_OFF // PLLKEN (PLLKEN_OFF)
#pragma config WINDIS = OFF // Watchdog Timer Window Enable bit (Watchdog Timer operates in Window mode)
#pragma config FWDTEN = ON_SW // Watchdog Timer Enable bit (WDT controlled via SW, use WDTCON.ON bit)
//#pragma config ICS = PGD1 // ICD Communication Channel Select bits (Communicate on PGC1 and PGD1)
#pragma config ICS = PGD2 // ICD Communication Channel Select bits (Communicate on PGC2 and PGD2)
#pragma config JTAGEN = OFF // JTAG Enable bit (JTAG is disabled)

#include <xc.h>

int main(void)
{
*(uint16_t *)0x12FE=0xAA55;
// _______________________ dsPIC33CH512MP508 / dsPIC33CH128MP508
// Post-increment examples
__asm("mov #0x12FF,w0"); // w0 = 0x12FF / 0x12FF
__asm("mov.b [w0++],w0"); // w0 = 0x00AA / 0x00AA
while (1)
{
Nop();
}
return 0;
}

 

Attached Image(s)

#72
Page: < 1234 Showing page 4 of 4
Jump to:
© 2019 APG vNext Commercial Version 4.5