| View previous topic :: View next topic |
| Author |
Message |
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
| RVREG bit in PCCON1 to be low on some restart? |
 Posted: Wed May 04, 2022 2:22 am |
 |
|
Any logic reason for the RVREG bit in PCCON1 to be low on some restart of a 18F27Q10 ?
-The code runs as expected after a reboot, only thing i see is the RVREG bit is low on some clean restarts.
--From Data sheet.
RVREG Main LDO Voltage Regulator Reset Flag bit
1 No LDO or ULP “ready” Reset has occurred; or set to ‘1’ by firmware
0 LDO or ULP “ready” Reset has occurred (VDDCORE reached its minimum spec) |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Wed May 04, 2022 3:09 am |
|
|
It will be low for most wake up's.
It has to be set to '1' by your firmware, if you want it to have any real
meaning.
If your code uses 'restart_cause', this adds the code to set this bit. So:
| Code: |
.................... int16 cause;
.................... cause=restart_cause();
00030: MOVF STATUS,W
00032: ANDLW 60
00034: MOVWF @00
00036: SWAPF @00,W
00038: MOVWF @01
0003A: RRCF @01,F
0003C: MOVLW 07
0003E: ANDWF @01,F
00040: BTFSC PCON1.RCM
00042: BCF 01.2
00044: BTFSS PCON1.RCM
00046: BSF 01.2
00048: BTFSS PCON1.RVREG
0004A: BCF 01.3
0004C: BTFSC PCON1.RVREG
0004E: BSF 01.3
00050: BSF PCON1.RVREG ;//note this line
00052: BCF PCON1.RCM
00054: MOVFF PCON0,00
00058: BTFSS PCON0.POR
0005A: BCF 00.0
0005C: BTFSS 00.0
0005E: BSF 01.2
00060: BTFSS 00.1
00062: BSF 01.2
00064: MOVLW 3F
00066: MOVWF PCON0
00068: CLRWDT
0006A: MOVFF 01,cause+1
0006E: MOVFF 00,cause
|
In the data sheet it says:
| Quote: |
Software should reset the bit to the Inactive state after restart. (Hardware will not reset the bit.)
|
The compiler does not do this unless you read restart_cause, since unless
you are using this the bit is effectively not being used.
'0' is the normal state. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Fri May 06, 2022 4:00 am |
|
|
Thanks for you post, but forget my first post, i was confused, and maybe this is confusing too, but take a look:-)
Really try to understand the crazy function restart_cause();
From CCS:
#define CONFIG_CORRUPTION 0xB3F.
How to be the B? It will look like this b1011.
Run restart_cause(); and then we have
| Code: | Byte @1 @0
Bit Pos: 7654|3210 | 7654|3210 |
| Code: | @1
b0=STATUS(b5) PD ->H=Set at power up
b1=STATUS(b6) TO ->H=Set at power up
b2=PCON1 (b0) RCM ->L=Error Config corrupt
b3=PCON1 (b2) RVREG ->L=Error LDO/ULP (Must be set H/1 by software)
4,5,6,7 are 0
|
To get the B, PD,TO,RVREG must be 1 and RCM must be 0.
Look at my star* in the assembler from the CCS function restart_cause(), i have NOT changed anything, only grouped it and comment it.
If it is wrong please help to clear it out?
---
| Code: | .................... int16 restart,tvar;
.................... restart=restart_cause();
#After this STATUS bit PD and TO is b0 and b1 in the high byte of int16 from restart_cause()
000E4: MOVF STATUS,W
000E6: ANDLW 60
000E8: MOVWF @00
000EA: SWAPF @00,W
000EC: MOVWF @01
000EE: RRCF @01,F
000F0: MOVLW 07
000F2: ANDWF @01,F
#Why invert the RCM bit? This can be the reason for the cold start showing 0x0Bxx can be an error?
#It is b2 in the int16 from restart_cause()
000F4: BTFSC PCON1.RCM * From a cold start this bit is 1
000F6: BCF 01.2 * clear bit
000F8: BTFSS PCON1.RCM *
000FA: BSF 01.2 * set bit
#look ok set is set and clear is clear. It is b3 in the int16 from restart_cause()
000FC: BTFSS PCON1.RVREG
000FE: BCF 01.3
00100: BTFSC PCON1.RVREG
00102: BSF 01.3
00104: BSF PCON1.RVREG
#
00106: BCF PCON1.RCM * Clear the bit for to detect on other/next use of restart_cause, on a reboot/reset
#PCON0 is now LowByte of the int16 in restart_cause()
00108: MOVFF PCON0,00 * load @0
#if POR clear BOR
0010C: BTFSS PCON0.POR Test POR_b1 for 0 and then Clear
0010E: BCF 00.0 Clear BOR_b0
#if POR is clear, set PCM
00110: BTFSS 00.1 * Test PCON0 bit 1 POR if 0 set RCM
00112: BSF 01.2 * Set RCM
#Preload PCON0 to be ready for next use of restart_cause() on a reboot/reset
00114: MOVLW 3F
00116: MOVWF PCON0 0011 1111
# Return
00118: MOVFF 01,restart+1
0011C: MOVFF 00,restart |
---
Confusing? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Fri May 06, 2022 4:39 am |
|
|
It's history.
They attempt to keep the bits in the same locations in the return from
restart_cause. So they migrate bits to match where they were in older
chips,and also invert bits that will be one on a normal restart, so you get
zero for the normal power wake up. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Fri May 06, 2022 6:54 am |
|
|
What i show explain why the RCM is not set (L or 0=Error Config corrupt)
This is an error in the way CCS handle it. So Complex to understand.
#define CONFIG_CORRUPTION 0xB3F. And i get it on cold boot.
I will ask CCS what they think about the RCM is 0 on boot. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Sat May 07, 2022 2:11 am |
|
|
The reason for the problem is the data sheet is wrong....
Read it. They says that RCM being '1' means a reset due to the config
being wrong has occurred. But they also say that from a cold start the
bit is '1', which is then saying that an error has occurred!...
Aargh.
No wonder CCS had problems....  |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Sun May 08, 2022 3:07 am |
|
|
Thanks for you hints, and i came up with something like, used so much time one this.
Now i just ignore the bit, i find it not reliable. Or error in Microchip documentation, or one more Errata to all the others:-)
This simple test are not using CCS function, just to have control over what is going on.
I use a clean program with only minimum to run in hw.
Cold restart
PCON1.RCM, bit 0 always set
reset_cpu() from sw, after cold start show the same.
Cold restart
PCON1.RCM, clear bit 0
reset_cpu() from sw
now the bit is always cleared.
| Code: | void RestartTest(){
int8 pc0,pc1,st;
#byte PCON0 = getenv("SFR:PCON0")
#byte PCON1 = getenv("SFR:PCON1")
#byte STATUS = getenv("SFR:STATUS")
pc0=PCON0;
pc1=PCON1;
st=STATUS;
fprintf(debug,"[PC1:%X PC0:%X ST:%X]\r\n",pc1,pc0,st);
//bit_set(PCON1,0);
bit_clear(PCON1,0);
while(1){
delay_ms(1000);
reset_cpu();
delay_cycles(4);
}
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Mon May 09, 2022 1:10 am |
|
|
Do report it to CCS.
They need to handle this bit by setting it after boot, just as with RVREG. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Tue May 10, 2022 1:44 am |
|
|
All the problem is two different datasheet from Microchip (date are at the most left on every page), one from 2019 and one from 2020.
**
In the one from 2019:
| Code: | Bit 0 – RCM Configuration Memory Reset Flag bit
Reset States: POR/BOR = 1
All Other Resets = q
Value Description
1 A Reset occurred due to corruption of the configuration and/or calibration data latches
0 The configuration and calibration latches have not been corrupted |
***
In the one from 2020:
| Code: | Bit 0 – RCM Configuration Memory Reset Flag bit
Reset States: POR/BOR = 1
All Other Resets = q
Value Description
1 The configuration and calibration latches have not been corrupted
0 A Reset occurred due to corruption of the configuration and/or calibration data latches
|
At my desk i have printed the one from 2019, and on my dev. comp i have opened the one from 2020.
Some time i read at my desk the 2019, one and sometime i read at the dev. comp the one from 2020.
Therefore i have used days to be so confused:-(
The bit must be set all time for to be a good boot. And i have tested that to be true in my prev. post:
Cold restart, PCON1.RCM, bit 0 always set. reset_cpu() from sw, after cold start show the same.
*
*CCS have a error in there restart_cause();
They invert the bit10 it is the PCON1.RCM bit and therefore the 0xBxx will show up.
After that they clear the bit, BCF PCON1.RCM for get ready to next detection, and this is right, because they invert it. But it is all wrong!!!
They have used the old data sheet from 2019 i think. I will try to report it but this is a hard one.
This was not for fun, or maybe a little:-) |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Tue May 10, 2022 3:56 am |
|
|
Thing to do is point out that it is 1 on a good boot, and the conflict in
the data sheet. It also conflicts with it's 'name' (/RVM) - this says it
is low for active. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Tue May 10, 2022 9:14 am |
|
|
| CCS will fix the bug in the next release. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Wed May 11, 2022 12:11 am |
|
|
Good.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
