| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19436
|
| PLL error PIC30F3013 |
 Posted: Sat Jan 09, 2016 10:15 am |
 |
|
This is the erratum 16:
| Quote: |
16. Module: PLL
The PLL LOCK Status bit (OSCCON<5>) can
occasionally get cleared and generate an
oscillator failure trap even when the PLL is still
locked and functioning correctly.
Work around
The user application must include an oscillator
failure trap service routine. In the trap service
routine, first inspect the status of the Clock Failure
Status bit (OSCCON<3>). If this bit is clear, return
from the trap service routine immediately and
continue program execution.
|
Now I have:
| Code: |
#byte OSCCON=getenv("SFR:OSCCON")
#INT_OSCFAIL
void oscillator(void)
{
if (bit_test(OSCCON,3)==0)
return; //if erratum immediately return
reset_cpu(); //otherwise crash
}
|
To handle this. Problem is that this incurs the overhead of CCS's huge number of register saves. This is giving me a timing problem.
Is there an easy way to code a fix for this, without the CCS overhead?. |
|
 |
newguy
Joined: 24 Jun 2004
Posts: 1904
|
|
| Posted: Sat Jan 09, 2016 10:44 am |
|
|
A couple years back I discovered a reset issue that was being triggered by loading UART2 (dsPIC33FJ256GP710A) and enabling the TBE2 interrupt. In desperation I asked CCS for help and they emailed me what appeared to be some custom error trap code that (from memory) seemed to be very "lean". Using that I was able to figure out the cause of the error, which turned out to be the compiler causing an address error or a math error (can't remember which). The problem turned out to be one of those "magic" errors that magically went away when I added more code to the project. I hate those.
Anyway, my suggestion would be to ask CCS if they can give you any routine(s) to help, or if they can suggest a workaround to the "automatic" code the compiler is automatically inserting for you. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19436
|
|
| Posted: Sat Jan 09, 2016 3:40 pm |
|
|
Agreed.
I was just hoping to 'short circuit', if somebody already had a solution. 
Assuming they won't be around till Monday. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1904
|
|
| Posted: Sat Jan 09, 2016 5:17 pm |
|
|
On new year's eve I discovered that our license files had expired and I emailed them not expecting a reply until the 4th. New year's day they sent the new files.
They might surprise you. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1334
|
|
| Posted: Sat Jan 09, 2016 7:59 pm |
|
|
| for PIC24 chips I use the FAST option in the #INT_XXX line. I don't know what that does for the DSPIC30 family though. EDIT: And I have never tried it in a trap interrupt. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19436
|
|
| Posted: Sun Jan 10, 2016 1:37 am |
|
|
Thanks Jeremiah. FAST does work. There is almost no difference between the PIC24, and 30.
It's quite a sensible implementation. Hardware pushes the PC, and stack frame, and the CCS code then just pushes the status register, and nothing else, and on the return clears the interrupt, and pops the status, which for the simple bit test, is exactly what is needed. Brings it down to just on a dozen machine cycles. Still a bit of a pain (I seem to have found an instruction sequence, that repeatedly triggers this error!). Currently trying other ways to code this to get rid of the problem.
I must admit the lack of documentation on the PIC24/30 for this is annoying, since obviously things are very different (you can't for example have 'INT_GLOBAL'). I was getting hooked on INT_GLOBAL being how I'd implement it on the PIC16/18, and forgot FAST. Will have to play more once this is working right.
Happy New Year everyone - don't think I have said this here this year yet!...
 |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1334
|
|
| Posted: Sun Jan 10, 2016 10:24 am |
|
|
| I haven't gone back to look for that chip, but a lot of the PIC24 documentation got moved out of the specific chip datasheet to the family reference manuals. Some of the stuff may be in one of those. I think the DSPIC30 series may also do the same. Though I don't know if it will have what you are looking for or not. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1904
|
|
| Posted: Sun Jan 10, 2016 10:37 am |
|
|
| The dsPIC33 family processors I've dealt with are the same. The data sheet is somewhat like a very brief/abridged Coles' Notes version with the real details in the FRM (family reference manual). |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19436
|
|
| Posted: Sun Jan 10, 2016 2:23 pm |
|
|
| Absolutely. The actual data sheet is about 30 sections, including different bits pieces for every peripheral, with many not quite working (for instance some of the settings actually have to use he reference manual for the 10 bit ADC, though this chip has the 12biit ADC...). The ADC doesn't actually quite work how the data says it should, if you follow the 12bit sheet... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
