osc advice

Discuss the Integrated Development Environment (IDE)

Moderators: David Barker, Jerry Messina

Post Reply
richardb
Posts: 316
Joined: Tue Oct 03, 2006 8:54 pm

osc advice

Post by richardb » Tue Aug 20, 2024 4:08 pm

Hi on a similar theme to the device config issue.


I have been having an issue with noise on a board that has a a pic18f47q43 in a socket its running with internal oscilator at 64MHz,

i originally had the config as below.

Code: Select all

Config
    FEXTOSC = OFF,      // Oscillator not enabled
    RSTOSC = HFINTOSC_64MHZ,// HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1
    CLKOUTEN = OFF     // CLKOUT function is disabled
    
and mostly this runs fine but under certain circumstances i have problems.
so i have designed a board that can plug into the old 40 pin socket of the 47q43 using a 57q43 and a seperate 16MHz xtal osc

so i tried running with new board which was ok but had the same problem and have now tried to disconnect the osc to prove that the pic is running from xtal but the pic still runs.

i'm using the confic below from the code generator.

Code: Select all

config
    FEXTOSC = HS,       // HS (crystal oscillator) above 8 MHz
    RSTOSC = EXTOSC_4PLL,// EXTOSC with 4x PLL, with EXTOSC operating per FEXTOSC bits
    CLKOUTEN = OFF,     // CLKOUT function is disabled
    PR1WAY = ON,        // PRLOCKED bit can be cleared and set only once
    CSWEN = ON,         // Writing to NOSC and NDIV is allowed
    FCMEN = OFF,        // Fail-Safe Clock Monitor disabled
    MCLRE = EXTMCLR,    // If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR 
    PWRTS = PWRT_OFF,   // PWRT is disabled
    MVECEN = OFF,       // Interrupt contoller does not use vector table to prioritze interrupts
    IVT1WAY = ON,       // IVTLOCKED bit can be cleared and set only once
    LPBOREN = OFF,      // Low-Power BOR disabled
    BOREN = SBORDIS,    // Brown-out Reset enabled , SBOREN bit is ignored
    BORV = VBOR_1P9,    // Brown-out Reset Voltage (VBOR) set to 1.9V
    ZCD = OFF,          // ZCD module is disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON
    PPS1WAY = OFF,      // PPSLOCKED bit can be set and cleared repeatedly (subject to the unlock sequence)
    STVREN = ON,        // Stack full/underflow will cause Reset
    LVP = ON,           // Low voltage programming enabled. MCLR/VPP pin function is MCLR. MCLRE configuration bit is ignored
    XINST = OFF,        // Extended Instruction Set and Indexed Addressing Mode disabled
    WDTCPS = WDTCPS_31, // Divider ratio 1:65536; software control of WDTPS
    WDTE = OFF,         // WDT Disabled; SWDTEN is ignored
    WDTCWS = WDTCWS_7,  // window always open (100%); software control; keyed access not required
    WDTCCS = SC,        // Software Control
    BBSIZE = BBSIZE_512,// Boot Block size is 512 words
    BBEN = OFF,         // Boot block disabled
    SAFEN = OFF,        // SAF disabled
    DEBUG = OFF,        // Background Debugger disabled
    WRTB = OFF,         // Boot Block not Write protected
    WRTC = OFF,         // Configuration registers not Write protected
    WRTD = OFF,         // Data EEPROM not Write protected
    WRTSAF = OFF,       // SAF not Write Protected
    WRTAPP = OFF,       // Application Block not write protected
    CP = OFF            // PFM and Data EEPROM code protection disabled
so my question is ..

should the pic run with no external xrystal? with this confic

is there a fallback oscilator that its running from ?

can somone suggest another config or think of a way to prove its running from the internal osc or the external one?



Thanks in advance.

Rich
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1487
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: osc advice

Post by Jerry Messina » Wed Aug 21, 2024 1:19 pm

That config looks correct for an external xtal + pll.
You should be able to see what's being used by looking at the COSC and CDIV bits in the OSCCON2 register, and along with OSCSTAT that should show the current osc status.

You have the fail-safe clock-switching disabled, so it shouldn't be running from that. If you don't have an xtal installed then it shouldn't run.

You mention you're having problems with "noise". Could you describe what you're seeing?
Is VDD ok? Decoupling caps on both sets of VDD/VSS pins?

I've found the int osc on the newer devices to be pretty reliable under normal temperature conditions...

richardb
Posts: 316
Joined: Tue Oct 03, 2006 8:54 pm

Re: osc advice

Post by richardb » Thu Aug 22, 2024 6:07 am

I was hoping I'd overlooked something, I'll try checking the registers you suggested.


I'm used to noise, I make Pulsed laser power supplies, the problem is that i have made a new PCB and one of the changes was using the intosc on this chip as i was low on pins and I haven't used it much before. So I am just trying to rule that out as a possible problem.

It will run perfectly fine without the laser running but when the laser runs the first think you notice is the lcd becomes corrupt, then the microcontroller stops responding to input.


Thanks again


Rich
Hmmm..

richardb
Posts: 316
Joined: Tue Oct 03, 2006 8:54 pm

Re: osc advice

Post by richardb » Tue Sep 03, 2024 6:18 am

Ok so an update.

After putting my debug kit back on the microcontroller i was getting a warning about buffer overrun when the problem was occuring.

Code: Select all

Sub CheckForNewData()
    Dim inbyte As Byte

    If ISRRX.BufferOverrun Or ISRRX.Overrun Then
            MyDebug("{OverRun}"+CrLf)
            ISRRX.Reset
    EndIf
    While ISRRX.DataAvailable 
	InByte =ISRRX.ReadByte 
        If inbyte <> 10 Then
		If Inbyte = 13 Then 
                UseUsbData (inbuffer)
                inbuffer=""    
            Else
                inbuffer =inbuffer + Char(InByte)
            EndIf
            
        EndIf
    Wend
End Sub

as a reminder this was causing display corruption and locking up of the pic.

this was traced back to a pulse coming into the pic usart of 1us long at 10 kHz ( the laser frequency).
i was using 57kbaud

when looking at the rs485 signal inputs there was a very small glitch in the inputs but only a few mV and shouldn't have been a problem but i noticed the inputs were at ground potential.

after biasing the rs485 signals it cured the problem completely.

so even though the bias resistors on rs485 are supposedly optional and not even mentioned in many data sheets.


In conclusion I would recommend bias resistors :)


Rich
Hmmm..

Post Reply