Register is overwritten

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Register is overwritten

1,093 Views
song_xianming
Contributor I

MCU : mc9s12g128

Compiler: codewarriory 5.1

During the running of the program, the pull-up register of the port is rewritten, and the pull-up function of the port is opened after the rewriting. After checking the software did not operate this register, I would like to analyze from hardware, software, compiler, and what are the reasons for rewriting the register. How to locate the reason why the register is abnormally overwritten.

0 Kudos
9 Replies

939 Views
kef2
Senior Contributor IV

regarding sudden change of register/variable. Hiwave debugger has watchpoints for this. You may set watchpoint right clicking on static storage variable in Data window, then choosing Set Watchpoint. You may set watchpoint as well for any 16-bit memory location including peripheral register. Go to show breakpoint/watchpoints, Watchpoint tab, fill in address, size of variable/register in bytes, choose read, write or read/write access mode. For sudden overwrite you certainly need write mode. Then click Add, OK and run your program. Debugger should stop a couple of instructions past write access.

0 Kudos

939 Views
song_xianming
Contributor I

It won't appear when debugging, is there any other way?

0 Kudos

939 Views
kef2
Senior Contributor IV

Hi,

what won't appear? Show watchpoints? You need to right click while mouse pointer is over (static storage?) variable, it won't appear right clicking over blank space in Data window. You can get to watchpoints as well via show breakpoints. Show breakpoints is accessible right clicking in your code or assembler window, perhaps you need to place your mouse pointer over some code line. While in breakpoints dialog, click watchpoints tab.

0 Kudos

939 Views
song_xianming
Contributor I

We can't reproduce this phenomenon in the company. Our product is the controller on the car. As long as the value of the PUCR register is overwritten, our product cannot sleep. The register was rewritten during the troubleshooting process in the 4S shop of the car. This is an accidental event, and the probability of occurrence is about 1/10000. And as long as the controller is powered off, we have never received the same problem again in the same car. I also want to reproduce this phenomenon in the company. So it is not feasible to find this problem by means of debug. Is there any other way?

0 Kudos

939 Views
kef2
Senior Contributor IV

S12G has built in debug module. Usually you use it for debugging, on breakpoint/watchpoint it stops MCU and waits for BDM commands. But debug module can be set to trigger SWI, which you can use to register write to PUCR event in car. Once you enter SWI handler and confirm it was caused by debug module, you may try to register PC trapped in debug module, register other info, etc.

0 Kudos

939 Views
song_xianming
Contributor I

I don't know how to do it, can you provide detailed setup methods or related documentation?

0 Kudos

939 Views
kef2
Senior Contributor IV

Hi,

 

You are asking a little too much. Detail instructions for something, which almost no one uses in its practice. Well, by now I have only S12XD board at hand, which has little different debug module. Perhaps later I'll try it on S12P, which should be more similar to S12G. By now only steps for S12XD:

 

Let’s start from simple thing, SWI handler to receive breakpoint event, blank for now, for(;;) loop to pause and make sure MCU lands in it

 

#pragma CODE_SEG __NEAR_SEG NON_BANKED

interrupt VectorNumber_Vswi void swiisr(void)

{

     for(;;) {        }

}

#pragma CODE_SEG DEFAULT

 

You should read carefully S12S Debug Module chapter in S12G datasheet. Should be quite similar to S12X. Let’s set up comparator B for S12XD

 

DBGC1 &= ~DBGC1_ARM_MASK; // unarm, make registers writeable

DBGC1 &= ~DBGC1_BDM_MASK; // choose SWI instead of BDM

DBGC1_DBGBRK = 2; // CPU12X breakpoints

DBGC1_COMRV = 1; // choose comparator B

   DBGXCTL =

       DBGXCTL_SZE_MASK * 0 // ignore compare size

     | DBGXCTL_NDB_SZ_MASK * 0

     | DBGXCTL_TAG_MASK *0 // TAG=1 are for code breakpoints, TAG=0 – data R/W breakpoints

     | DBGXCTL_BRK_MASK *1 // immediate breakpoint

     | DBGXCTL_RW_MASK *0 // match write cycle

     | DBGXCTL_RWE_MASK *1 // R/W used in comparison

     | DBGXCTL_SRC_MASK *0 // CPU

     | DBGXCTL_COMPE_MASK*1; // enable comparator

    

   DBGXAH = (unsigned long)&PUCR >> 16; // PUCR address

   DBGXAM = (unsigned long)&PUCR >> 8;

DBGXAL = (unsigned long)&PUCR ;

 

DBGSCRX = 2; // any match triggers to final state

 

DBGC1 |= DBGC1_ARM_MASK; // arm module, required to enable breakpoint

 

 

Now you may wish to check it works, add some code to write PUCR,

PUCR=PUCR ; // or something like that

 

Once you enter debugger, you should go to HC12MultilinkCyclonePro->Trigger Module Settings.. and switch from Automatic to Disabled to stop debugger using debug module. Now you have debugger breakpoints broken, but working your “sudden PUCR overwrite” catcher.

 

Now one or more problems arise. If you are using preemptive RTOS, chances are SWI handler is used for RTOS purposes. You could then try reconfiguring your RTOS to use TRAP handler instead of SWI or perhaps add code to distinguish, was it your PUCR breakpoint or normal RTOS usage. On S12XD you can check for DBGC1_ARM bit in SWI handler. Occurrence of breakpoint seems reseting DBGC1_ARM bit.

Another thing you should consider misaligned word write to MODE@0xB, which will overwrite PUCR@0xC as well. You need to setup at least two breakpoints. One for byte/word write to 0xC (PUCR) and another one for word write to 0xB. At least on S12XD DBG module looks for destination address, not for matching aligned word address. What I see on S12XD, when address is odd, both byte and misaligned word write to given odd address trigger breakpoint, but don’t trigger doing aligned word write. The question is what about instructions like EMACS? EMACS writing 32bits to 0x9..0xC will overwrite PUCR, but will it trigger breakpoint? We need to check. If not, then you should setup address range compare breakpoint and consider all write hits to 0x9..0xC as potential PUCR overwrite events.

And the last thing is deducing PC location which triggered PUCR overwrite breakpoint. 16bit return address from SWI handler is at SP+7 for S12 and SP+8 for S12X. Don’t forget about possible stack frame.

Edward

0 Kudos

939 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello,

Could you please specify the port?

What is the default pull configuration of the port? Please refer to the Pinout tables in the S12G RM.

What is the overwritten value of the corresponding Pull Device Enable Registers and Polarity Select Registers?

pastedImage_1.png

Thank you, 

BR, Daniel

0 Kudos

939 Views
song_xianming
Contributor I

The overwritten register is PUCR. Normally, its value is 0x50. After the exception is overwritten, its value is 0x5E. This phenomenon is sporadic. The probability of occurrence is relatively low. Debugging will not appear at all. We tested the software and there was no array overflow or pointer overflow. I am very surprised and have a headache with this question. Can not explain the reason with our customers.

pastedImage_1.png

0 Kudos