PIC24EP problem, double rmw to io register fails - Page 1
Forum section: electronics / general

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 25, 2018, 04:50:39 pm
content: For example if you use bset twice to the same io register (different bits) sometimes it fails and not always the second! In my particular case this is to a register within the HSPWM so may be specific to that peripheral. Adding a nop or two between sucsessive rmw's doesnt work so the only alternative when bit twiddling multiple bits is do it in a shadow register and load it in a single mov, that worksI hope this helps others rather than attract unwarented comments. This is not in the Errata.

author: kony
author_rank: Regular Contributor
timestamp: February 25, 2018, 05:14:50 pm
content: Are you sure you are witing to the output shadow register and not the port I/O one? Similar thing happens with 18F families, write to PORTx sometimes works, but as it is R/M/W with the actual values present on the I/O port, it can go corrupt if something pulls or glitches the output value at the time of execution of the instruction. Hence why shadow output LATx register set is present (which gets automatically copied to PORTx enabled outputs).

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 25, 2018, 05:41:46 pm
content: Sorry I did clearly state "register within the HSPWM" nothing to do with port i/o. It is however an io register with respect to the cpu, i.e. not a cpu core register, hope that clarifies things

author: Benta
author_rank: Super Contributor
timestamp: February 25, 2018, 08:06:51 pm
content: Back in the early 80s when I learned coding (assembler in those days), I got burned so bad using RMW instructions on peripherals, that I made myself a promise never to do that again.If I use an RMW, then only on RAM, and only on single-CPU systems.One issue is, that justreadingvalues from a peripheral can change the value. As an example, reading an interrupt register clears the interrupt, because the peripheral interprets this as the interrupt being serviced (which is correct from the peripheral's point of view).I suggest you do atomic reads, modifies and writes, because only in that way are you in control of what happens.Compilers usually do the same, by the way.

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 26, 2018, 07:46:50 pm
content: Thank you for your insight, as an assembler programmer I tend to make full use of the offered instruction set and get a bit peeved when it doesnt work! However in the case of this processor the peripherals run at half the core clock speed so I am not entirely suprised at the defect. Given Microchip seem to have abandoned assembly programmers (see peoples comments about MPLAB-X etc) I would expect all there testing is performed using C and as you pointed out the compiler avoids rmw. rmw is a heavely used construct particuarly in multiprocessing for indivisable lock flags so given C compilers apparently avoid this at all times some programming problems must prove interesting

author: andersm
author_rank: Super Contributor
timestamp: February 26, 2018, 08:12:05 pm
content: Does it help if you read back the register after writing (or at least before the next write)? That functions as a workaround for bus synchronization issues on some devices.

author: Benta
author_rank: Super Contributor
timestamp: February 26, 2018, 08:28:39 pm
content: Quote from: fourtytwo42 on February 26, 2018, 07:46:50 pmThis is not quite true. CPU architects are aware of this issue and have evolved special RMW instructions for multiprocessor systems.For example, the M68k architecture provides the TAS instruction, which is an indivisible RMW, meaning it locks the bus until it completes. This is in contrast to normal RMWs (like BSET), where bus arbitration may happen during instruction execution (and subsequent catastrophic results).

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 26, 2018, 08:39:54 pm
content: I must confess as the indivisability of the rmw was not an issue in this application I didnt spend a lot of time investigating it further. I can say by observation a 3rd rmw some long time after the first two adgacent ones flushes the missing write of whichever failed, very mysterious indeed but not having a description of there synchroniser it's difficult to imagine the circumstances. The failure rate is also quite random, it is however very typical of a metastable condition oops!!If you wish to try testing this try using bset & bclr on pairs of bits in the PWM IOCONx register specifically the OVRDAT bits, you need a scope on the PWMx outputs to see the problem, I am running the cpu at ~40Mips.

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 26, 2018, 08:55:45 pm
content: Quote from: Benta on February 26, 2018, 08:28:39 pmYes well Microchip are long past the point where they provide such detailed information to there users, however in this case where only a single processor is in use and there is no other active bus master the rmw has clearly failed due to the intracasies of there synchronisation logic nececiated by the core running at twice the peripheral frequency. To muddy the waters with what compilers do or not and other processor architectures does not help others to be warned about the simple point I have outlined.

author: Benta
author_rank: Super Contributor
timestamp: February 26, 2018, 10:04:36 pm
content: 42, if you are pissed off at the PICs, I understand you. In my personal opinion they were always crap.But the best parts don't always win. PICs are popular because Microchip marketing catered to hobbyists and students, the big players ignored them. Students turn into engineers, though. And suddenly PICs are mainstream.I still think they are not well designed and would never use one myself.Feel better? Probably not, but you now know my opinion.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: February 26, 2018, 10:18:41 pm
content: Quote from: fourtytwo42 on February 25, 2018, 04:50:39 pmWhich PIC24EP, and can you show us the code that fails? How often does it fail?

author: Howardlong
author_rank: Super Contributor
timestamp: February 26, 2018, 11:12:01 pm
content: Happy to try it here, I have both PIC24EP256GP202 and PIC24EP256MC202 in stock if that helps. I have EP series with a larger numbers of pins in stock but they're less easy to breadboard.Are you saying the RMW just is not working, or that the peripheral takes no notice of the setting?I am wary of setting out on writing my own PWM code on this device as this specific PWM peripheral is very complex: I did some work on a dsPIC33 with a similar PWM peripheral a couple of years ago, it takes a lot of time to understand and get right. Happy to try your example code.What I do note, if it's a PIC24EPXXXMC20X, that there's a config bit PWMLOCK that locks you out of changing the IOCONx and FCLCONx registers unless you write 0xABCD and 0x4321 to the PWMKEY register first. Section 16.1.2 of the datasheet, DS70000657H, page 226.The code below I tested on a PIC24EP256MC202 and it won't set the bit on the register unless I compile the code with #pragma config PWMLOCK = OFFCode:// PIC24EP256MC202 Configuration Bit Settings// 'C' source line config statements// FICD#pragma config ICS = PGD3 // ICD Communication Channel Select bits (Communicate on PGEC3 and PGED3)#pragma config JTAGEN = OFF // JTAG Enable bit (JTAG is disabled)// FPOR#pragma config ALTI2C1 = OFF // Alternate I2C1 pins (I2C1 mapped to SDA1/SCL1 pins)#pragma config ALTI2C2 = OFF // Alternate I2C2 pins (I2C2 mapped to SDA2/SCL2 pins)#pragma config WDTWIN = WIN25 // Watchdog Window Select bits (WDT Window is 25% of WDT period)// FWDT#pragma config WDTPOST = PS32768 // Watchdog Timer Postscaler bits (1:32,768)#pragma config WDTPRE = PR128 // Watchdog Timer Prescaler bit (1:128)#pragma config PLLKEN = OFF // PLL Lock Enable bit (Clock switch will not wait for the PLL lock signal.)#pragma config WINDIS = OFF // Watchdog Timer Window Enable bit (Watchdog Timer in Non-Window mode)#pragma config FWDTEN = OFF // Watchdog Timer Enable bit (Watchdog timer enabled/disabled by user software)// FOSC#pragma config POSCMD = NONE // Primary Oscillator Mode Select bits (Primary Oscillator disabled)//#pragma config OSCIOFNC = ON // OSC2 Pin Function bit (OSC2 is general purpose digital I/O pin)#pragma config OSCIOFNC = OFF // OSC2 Pin Function bit (OSC2 is clock output)#pragma config IOL1WAY = OFF // Peripheral pin select configuration (Allow multiple reconfigurations)#pragma config FCKSM = CSECMD // Clock Switching Mode bits (Clock switching is enabled,Fail-safe Clock Monitor is disabled)// FOSCSEL#pragma config FNOSC = FRC // Oscillator Source Selection (Internal Fast RC (FRC))//#pragma config PWMLOCK = OFF // PWM Lock Enable bit (PWM registers may be written without key sequence)#pragma config PWMLOCK = ON // PWM Lock Enable bit (Certain PWM registers may only be written after key sequence)#pragma config IESO = OFF // Two-speed Oscillator Start-up Enable bit (Start up with user-selected oscillator source)// FGS#pragma config GWRP = OFF // General Segment Write-Protect bit (General Segment may be written)#pragma config GCP = OFF // General Segment Code-Protect bit (General Segment Code protect is Disabled)// #pragma config statements should precede project file includes.// Use project enums instead of #define for ON and OFF.#include <xc.h>int main(void){TRISBbits.TRISB5=0;while (1){Nop();LATBbits.LATB5=1;LATBbits.LATB5=0;IOCON1bits.OSYNC=1;Nop();IOCON1bits.OSYNC=0;Nop();}return 0;}Code:38500300FA0000mainLNK #0x038600302A9AE10BCLR TRISB, #538700304000000NOP38800306A8AE14BSET LATB, #538900308A9AE14BCLR LATB, #53900030AA80C22BSET IOCON1, #03910030C000000NOP3920030EA90C22BCLR IOCON1, #039300310000000NOP3940031237FFF8BRA 0x304Edit: Note that I get the same behaviour with the OVRDAT0 bit.

author: JPortici
author_rank: Super Contributor
timestamp: February 27, 2018, 07:08:34 am
content: Quote from: Bruce Abbott on February 26, 2018, 10:18:41 pmi remember him complaining about MPLABX, that it was extremely slow but omitting the completely irrelevant information that he was using an ancient PC with no SSDI also want to know the part and the code so i can crosscheck, the HSPWM is a relatively newer and complex peripheral and there are caveats in how and when to write to certain register.It's very possible that in some of the register you can't perform two RMW instructions in a row, and that it is stated in either the datasheet or the reference manual or both.Regarding unlocking, as with other simillar operations the compiler provides builtins that guarantees the correct excecution of the unlocking sequence. they are described in the compiler manual and used in the examples provided in the reference manual

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: February 27, 2018, 11:00:19 am
content: Quote from: JPortici on February 27, 2018, 07:08:34 amYeah we know, if you don't have the very latest top-of-the line hardware it'syourfault if the bloatware runs slow.QuoteOr it's just buggy, but once again that'syourfault for not having the latest chip revision (or if a bug-free version hasn't been released yet, expecting it to work...).They tell me that any PIC with less than 5 digits is deprecated and I'm a criminal for running Windows XP, but I don't care. MPlab8 and PicKit2 may not do the latest PICs, but they work better and I don't need the latest PICs for my projects. My hobby isretrocomputing - and now my MCUs and development tools are too!Quote from: fourtytwo42which is a pity because that was their strong suit, making up their mediocre performance compared to other brands.Anyway as an assembler programmer myself I am curious to see your code, as I have a few PIC24F's that I might want to use some day.

author: Howardlong
author_rank: Super Contributor
timestamp: February 27, 2018, 12:19:21 pm
content: “Latest top of the range hardware”... like the ICD4, which I discovered doesn’t debug the PIC24EP (along with quite a few others, at least not even slightly reliably).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 27, 2018, 02:01:37 pm
content: PIC24 bad enough, but PIC24E?I've worked on a project using that... the software guys didn't have much hair left.As the hardware guy, I was in and out of that project in a couple months; the software guys put several years into it! (Not that that's necessarily an implication against the CPU; you don't go that long without having concerns about project management or feature creep.)It should be no surprise that the new-design boards for that customer used STM32s... (The PIC24E persisted for two reasons: 1. adapting and improving existing customer design; 2. existing customer codebase.)Tim

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 27, 2018, 02:20:06 pm
content: Quote from: JPortici on February 27, 2018, 07:08:34 amIf you wish to troll people go find someone else I can do without the likes of you!

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 27, 2018, 02:29:40 pm
content: Thank you for your reply's first of all some codemov #iocon2init,w0mov w0,IOCON2; bset IOCON2,#OVRDAT1; bset IOCON2,#OVRDAT0The commented out stuff doesnt work, the single mov worksSo let me see, well I dont hate pics in fact I have been using them for years, I only made this post in case some other poor sod is trying to figure out why his/her code isn't working.Yes tim I like the STM32 also but I dont use it because I am still building cpu's without pcb's in a small space, this does admitedly cause me problems with restricted numbers of io pins. For the present project a gti I can just about manage with this part (PIC24EP256MC202) but it's a close thing! I do pcb's sometimes for example audio dsp's where dip simply isnt available but I like to keep my costs down. Also when handling high power devices it's essential IMOP to have absolute control and do things fast hence assembly preferance. I have/do write tons of C for BIG processors but I dont consider a PIC in that way, its just an itsy bitsy machine control engine

author: Howardlong
author_rank: Super Contributor
timestamp: February 27, 2018, 02:54:45 pm
content: Can you please give more context?I may have missed it, but I couldn't see any reference regarding your PWMLOCK config bit setting.

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 27, 2018, 03:29:01 pm
content: I am sorry you may have missed it because I dont dump irrelevent information here, if it were wrong (that it isn't) then how would one peice of code work and the other not ?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 27, 2018, 03:56:03 pm
content: Quote from: fourtytwo42 on February 27, 2018, 02:29:40 pmSpeaking of C, the aforementioned project is all in C, just to fill that in..I imagine, between libraries and early consternations, they solved low level register problems long ago. Though I think there were still a few hangups here and there? So, eh.. if you want to re-invent the wheel, you're welcome to, and you'll re-discover along the way many of the catches that happen, like the above.Tim

author: JPortici
author_rank: Super Contributor
timestamp: February 27, 2018, 04:37:45 pm
content: Quote from: Bruce Abbott on February 27, 2018, 11:00:19 amI referenced that thread because apparently this was some "irrelevant information" when complaining about MPLABX.It was not. My 2010 macbook with an SSD was fast enough, sure it took like 30 seconds to finish loading MPLABX compared to 5 in my current PC. And my current PC is a 7th gen NUC, nothing really fancy.Quoteperhaps, but if the documentation states that you can't do successive RMW instructions in certain register, it's not a bug.Quotenot at allyou are free to do what you want and i'm free to always suggest moving to modern/better/cheaper parts forwork. I also take different choices in my hobby projectsQuoteor maybe the information is there somewhere you haven't looked. which is why asking for the part number is not asking to provide "irrelevant information".documentation quality has gone down the drain compared to like 5 years ago, but i still think it's one of the best against say ST or ATMEL, or even NXP(Kinetis)sorry for you, but i'm not trolling. i'm really trying to help.

author: cv007
author_rank: Frequent Contributor
timestamp: February 27, 2018, 08:12:36 pm
content: QuoteIts relevant for this reason- IF you have PWMLOCK on, and you are not showing the 'irrelevant' code previous which does the unlock, then it could explain a problem-your code (this is all we get to see)-mov #iocon2init,w0mov w0,IOCON2; bset IOCON2,#OVRDAT1; bset IOCON2,#OVRDAT0maybe you are doing the unlock before this (we don't know), which could explain why the mov works and the bset does not.According to the datasheet, the PWMUNLOCK sequence requires that the first sfr access following has to be a WRITE, so if using bset a read is thrown in there first which may prevent the write taking place since the unlock just failed. The mov would work as a WRITE is the first sfr access after the unlock code.This may not be the case, but it certainly is a possibility. If you have PWMLOCK off, then never mind (but again, how would we know).

author: Howardlong
author_rank: Super Contributor
timestamp: February 27, 2018, 08:54:30 pm
content: Quote from: cv007 on February 27, 2018, 08:12:36 pmPrecisely.I'm now not sure I should've spent the hour or so I've burned trying to reproduce the OPs problem in real hardware. At the moment, I am unable to reproduce it, unless the PWMLOCK config bit is set. Therefore, I don't see it as a bug, it is by design, unless I can be shown the precise context, including any unlock sequences and the PWMLOCK config bit.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: February 28, 2018, 12:50:07 am
content: Quote from: JPorticiFair enough, but the 'irrelevant' reference to MPLabx was a bit obtuse so next time you might try being more direct (and BTW you shouldn't need an SSD to get reasonable performance).I agree that the OP should provide sufficient code to reproduce the problem. That means including all the config bits and initialization code, preferably as part of aMinimal, Complete, and Verifiable Examplethat still fails with all (truly) irrelevant bits stripped out.Quote from: fourtytwo42 on February 27, 2018, 02:29:40 pmYou said "if you use bset twice to the same io register (different bits)sometimesit fails and not always the second". So does the code above fail sometimes, or always? Can you show an example of similar code thatdoesn'tfail?

author: Howardlong
author_rank: Super Contributor
timestamp: February 28, 2018, 08:45:09 am
content: 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: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");

author: JPortici
author_rank: Super Contributor
timestamp: February 28, 2018, 10:12:38 am
content: Quote from: fourtytwo42 on February 27, 2018, 02:29:40 pmAnd that's what is supposed to happen! Current datasheet for PIC24EP with HSPWM:http://ww1.microchip.com/downloads/en/DeviceDoc/70000657H.pdfparagraph 16.1.2 Write Protected registersQuoteit 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 registerCode:; FLT32 pin must be pulled low externally in order to clear and disable the fault; Writing to FCLCON1 register requires unlock sequencemov #0xabcd,w10 ; Load first unlock key to w10 registermov #0x4321,w11 ; Load second unlock key to w11 registermov #0x0000,w0 ; Load desired value of FCLCON1 register in w0mov w10, PWMKEY ; Write first unlock key to PWMKEY registermov w11, PWMKEY ; Write second unlock key to PWMKEY registermov w0,FCLCON1 ; Write desired value to FCLCON1 register; Set PWM ownership and polarity using the IOCON1 register; Writing to IOCON1 register requires unlock sequencemov #0xabcd,w10 ; Load first unlock key to w10 registermov #0x4321,w11 ; Load second unlock key to w11 registermov #0xF000,w0 ; Load desired value of IOCON1 register in w0mov w10, PWMKEY ; Write first unlock key to PWMKEY registermov w11, PWMKEY ; Write second unlock key to PWMKEY registermov w0,IOCON1 ; Write desired value to IOCON1 registerother 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.

author: JPortici
author_rank: Super Contributor
timestamp: February 28, 2018, 10:30:34 am
content: 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)

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 28, 2018, 10:58:03 am
content: This really is tiresome, another code snippetconfig __FOSCSEL,FNOSC_FRCPLL & PWMLOCK_OFFIf 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.

author: Howardlong
author_rank: Super Contributor
timestamp: February 28, 2018, 02:51:30 pm
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 28, 2018, 05:49:51 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: February 28, 2018, 09:21:05 pm
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: March 13, 2018, 08:25:33 am
content: 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 ismov #66,w0mov w0,PHASE3And the watch window after a breakpoint just afterwardsPHASE3 0x1200 4608 00010010 00000000If however I single step (F7) the same code it worksSo far I have changed the chip, same result, they are both mask A3, nothing apparent in errataI 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 indeedBTW 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

author: Howardlong
author_rank: Super Contributor
timestamp: March 13, 2018, 09:35:11 am
content: Give us a complete, concise, reproducible example of this happening.

author: fourtytwo42
author_rank: Super Contributor
timestamp: March 13, 2018, 09:47:31 am
content: 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 sensativeBUT 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

author: Howardlong
author_rank: Super Contributor
timestamp: March 13, 2018, 10:29:18 am
content: Quote from: fourtytwo42 on March 13, 2018, 09:47:31 amWhich 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: March 13, 2018, 12:09:23 pm
content: OMG I find this hard to beleive BUT it seems somebody at Microchip thought it would be a good idea to ENABLE INTERRUPTS BY DEFAULTThats 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

author: Howardlong
author_rank: Super Contributor
timestamp: March 13, 2018, 01:49:28 pm
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: March 13, 2018, 03:47:44 pm
content: 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.EDITAfter 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..........

author: bson
author_rank: Unknown
timestamp: March 16, 2018, 12:40:28 am
content: Quote from: fourtytwo42 on February 28, 2018, 10:58:03 amDo you have interrupts disabled? An interrupt at the wrong time would "steal" your unlock cycle.Edit: never mind