PIC24EP problem, double rmw to io register fails

[Howardlong]

FWIW the following code segment reproduces the alleged problem if you have the PMWLOCK config bit set. If the PMWLOCK config bit is OFF, the OVRDAT bits do set. But this behaviour to me is as designed and documented.

Code: [Select]

        asm("mov #0xabcd,w10 ; Load first unlock key to w10 register");
        asm("mov #0x4321,w11 ; Load second unlock key to w11 register");
        asm("mov #0xF000,w0 ; Load desired value of IOCON2 register in w0");
        asm("mov w10, PWMKEY ; Write first unlock key to PWMKEY register");
        asm("mov w11, PWMKEY ; Write second unlock key to PWMKEY register");
        asm("mov w0,IOCON2 ; Write desired value to IOCON2 register");
        asm("bset   IOCON2,#7 ; #OVRDAT1");
        asm("bset   IOCON2,#6 ; #OVRDAT0");


[JPortici]

Thank you for your reply's first of all some code
   mov      #iocon2init,w0
   mov      w0,IOCON2
;   bset   IOCON2,#OVRDAT1
;   bset   IOCON2,#OVRDAT0
The commented out stuff doesnt work, the single mov works

And that's what is supposed to happen! Current datasheet for PIC24EP with HSPWM: http://ww1.microchip.com/downloads/en/DeviceDoc/70000657H.pdf

paragraph 16.1.2 Write Protected registers

On dsPIC33EPXXXMC20X/50X and PIC24EPXXXMC20X devices, write protection is implemented for the IOCONx and FCLCONx registers.
The write protection feature prevents any inadvertent writes to these registers.
This protection feature can be controlled by the PWMLOCK Configuration bit (FOSCSEL<6>). The default state of the write protection feature is enabled (PWMLOCK = 1).
The write protection feature can be disabled by configuring, PWMLOCK = 0.

To gain write access to these locked registers, the user application must write two consecutive values of (0xABCD and 0x4321) to the PWMKEY register to perform the unlock operation.
The write access to the IOCONx or FCLCONx registers must be the next SFR access following the unlock process. There can be no other SFR accesses during the unlock process and subsequent write access.
To write to both the IOCONx and FCLCONx registers requires two unlock operations.

it was written there the whole time. you can perform only one operation after the unlock sequence, so it was not a bug. It's implemented this way and the code example immediately below uses a mask register

Code: [Select]

; FLT32 pin must be pulled low externally in order to clear and disable the fault
; Writing to FCLCON1 register requires unlock sequence
mov #0xabcd,w10 ; Load first unlock key to w10 register
mov #0x4321,w11 ; Load second unlock key to w11 register
mov #0x0000,w0 ; Load desired value of FCLCON1 register in w0
mov w10, PWMKEY ; Write first unlock key to PWMKEY register
mov w11, PWMKEY ; Write second unlock key to PWMKEY register
mov w0,FCLCON1 ; Write desired value to FCLCON1 register

; Set PWM ownership and polarity using the IOCON1 register
; Writing to IOCON1 register requires unlock sequence
mov #0xabcd,w10 ; Load first unlock key to w10 register
mov #0x4321,w11 ; Load second unlock key to w11 register
mov #0xF000,w0 ; Load desired value of IOCON1 register in w0
mov w10, PWMKEY ; Write first unlock key to PWMKEY register
mov w11, PWMKEY ; Write second unlock key to PWMKEY register
mov w0,IOCON1 ; Write desired value to IOCON1 register
other peripherals have the same unlock mechanism: For example NVM erase/write operation and clock switching. in each case if you want to program in C and be sure that you perform the correct operations there are builtin functions, documentation at the end of the XC16 compiler manual.
Hope this helped.

[JPortici]

Side note, a reason to state why partnumber is NEVER irrelevant:
Reference manual tells what the complete peripheral is and how it behaves. The datasheet tells what is the actual implementation that may have differences from the ref manual.

For example the ADC2 in the dsPIC33EP MU series is slightly different than ADC1 and the differences are only in the datasheet.

Or there are different versions of the same peripheral, like 3 kinds of ADC (the 10 bit only, the 10/12 bit and multi-core the 12 bit used in the GS series which i think is pulled from the PIC32 MZ) and 2 different I2C, one is simillar to (or the same as) PIC32 MX.
Which one to use? Check different manuals? Better check the datasheet to see which one it uses first.

And different chips in the same family can have different errata documents.

(For example pic18f24/25K42 has or used to have different errata documents than 26/27K42)

[fourtytwo42]

This really is tiresome, another code snippet

config  __FOSCSEL,FNOSC_FRCPLL & PWMLOCK_OFF

If you READ the post you will find I state that it fails perodically, this is NOT a STATIC problem.

Now perhaps you will leave this thread alone and stop obscuring it with vast quanteties of information that is not applicable to this problem. In any case I don't require any help, the post was for information only.

[Howardlong]

Give us a full, concise reproducible example and we'll be happy to help. I have been unable to reproduce the problem on real hardware.

[fourtytwo42]

Of course it might be rev/id specific I should have mentioned mine are 4003 that is mask A3.
I am sorry I am not prepared to disclose my code on any public forum but I can say the circumstances are periodic timer driven setting and resetting of these bits. The failure is not continious and is typically corrected by a subsiquent rmw some time later. The failure can only realistically be observed using a scope on the output pins.

[Howardlong]

You don’t have to disclose your entire application.

Just a compact example of a reproducible scenario. That is -the- standard way to analyse and disclose bugs.

Without that it’ll remain nothing more than internet heresay.

[fourtytwo42]

After no more problems for several weeks another one has arisen again involving register writes of the HSPWM module but this time a simple mov instruction! The code snippet is
   mov      #66,w0   
   mov      w0,PHASE3
And the watch window after a breakpoint just afterwards
PHASE3   0x1200   4608   00010010 00000000
If however I single step (F7) the same code it works 

So far I have changed the chip, same result, they are both mask A3, nothing apparent in errata
I will see if enhancing the decoupling makes any differance, added extra 100nF every pwr pin pair, no change.
In previous versions of code this particular code worked fine, makes me very worried indeed 
BTW this is during initialisation so interrupts are disabled.

I should mention this is my first use of PIC24EP I have never experienced anything like this with 18F's etc, my tools are PK3 & MPLAB 8.92

[Howardlong]

Give us a complete, concise, reproducible example of this happening.

[fourtytwo42]

I knew you would say that and your right, I am going to have to make a new progect just to try and isolate these problems and I have a funny feeling when I do they will evaporate, in other words it's some nasty combinitorial problem potentially code location sensative BUT I either have to find out what's wrong or abandon this chip as I cannot have random register uncertainty everytime I rebuild the code for some reason

[Howardlong]

I either have to find out what's wrong or abandon this chip as I cannot have random register uncertainty everytime I rebuild the code for some reason

Which is precisely why you need a concise reproducible example. I’m not saying it’s easy, especially as those newer PWM peripherals are bitches to configure.

[fourtytwo42]

OMG I find this hard to beleive BUT it seems somebody at Microchip thought it would be a good idea to ENABLE INTERRUPTS BY DEFAULT Thats a completely new one on me and I cannot think of a processor I have used in 40ish years where the designer thought, I know let's do something weird and enable interrupts by default, wowww good thinking guys thank you soooooooooooooooooooooooo much

[Howardlong]

The interrupt sources aren’t enabled by default, you have to explicitly do that yourself.

The PiC24 and dsPIC families use the DISI instruction to disable global interrupts for a given finite number of cycles. If you want to permanently disable interrupts, you’ll need to run at IPL 7 by setting the IPL bits in the SR register. That’s not something I’m recommending for productiion code, but if you’re trying to figure something out it might make sense temporarily.

[fourtytwo42]

I do apologise I should have been clear, I meant the GIE bit in INTCON2.
To add to my woes I have now discovered the PicKit3/MPASM suite can adversly affect internal operation if in debug mode, even with no breakpoints set certain register writes fail possibly because they are in a watch list though I have not confirmed that yet (but I thought those were only updated when the cpu halted). This is certainly proving to be an unstable platform compared to what I am used but that may also be because it's the first time I have used it.
EDIT
After an hour or so of trying different combinations of with/without PK3, program/debug mode, reset or not, pwr cycle or not, guess what, the write problem on that particular register went away!! perhaps it's now cropped up somewhere else I have yet to discover..........

[bson]

If you READ the post you will find I state that it fails perodically, this is NOT a STATIC problem.

Do you have interrupts disabled?  An interrupt at the wrong time would "steal" your unlock cycle.

Edit: never mind