CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC Poltergeists or when new chips have fun errata

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PIC Poltergeists or when new chips have fun errata
PostPosted: Thu Jun 28, 2018 6:32 pm     Reply with quote

So this is more of a PSA about some of the newer chips being supported by CCS. To be upfront, this is totally a microchip issue, so no blame on CCS, but I figured since I have seen an uptake in PIC24 family part questions, some of the newer chips might cause fun landmines for other forum goers.

We got a PIC24FJ1024GB610 to use on a custom development board we designed in house. The board has LCD, buzzer, buttons, switches, tons of LEDs, etc. Recently we ported an old project code to the board while we were waiting for some new production boards to be made in hopes of getting a jump on the software development. Production boards don't use things like LCD or buzzers. We ported and verified all the pins and did a sanity check on the code to make sure it all ran correctly.

The code started throwing resets with a restart cause of "TRAP Error". So I threw in a small routine to grab the address in a trap ISR, but oddly, the ISR never fired. Furthermore, after adding the ISR, the buzzer and LCD started randomly coming on. This was very odd considering we verified that the pins associated with those two peripherals were no where referenced in the code.

About a day later, I decided to check the errata because I remembered some chips had special combinations that would generate trap errors. Low and behold this gem:

Quote:

The Primary Oscillator Start-up Timer (OST)
may indicate the oscillator is ready for use too
early. Clocking the device before the oscillator is
ready may result in incorrect execution and
exceptions. This issue exists when the POSC is
requested at power-on, during clock switching,
when waking from Sleep or when a peripheral
module requests the POSC directly. This issue
affects XT and HS modes only.


Sure enough if I either took out the sleep() instruction or I switched the FUSES and clock statement to use the FRC, the problems all went away. I am pretty sure the trap restart causes I was seeing were just incorrect restart cause values (since the ISR never fired).

So this was totally my fault for not checking the errata, but I am bringing this up because we have found quite a few more of the newer large pin count chips with this same or similar errata. So if you start seeing poltergeists one day, do a sanity check, or better yet check the errata before committing to a PIC for a new board design (I'm old enough to already know this but everyone makes mistakes).
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jun 29, 2018 12:43 am     Reply with quote

Quite a few of the bigger PIC's, require you to wake on the RC oscillator, and then switch to the crystal. What is particularly nasty about the erratum noted, is that it also affects switching in software.

The workround they show is to run in FRC, then enable the primary oscillator to operate a peripheral, wait long enough for it to have started and stabilised, then switch to it. A bit long winded but should get it working. You notice they suggest this when clock switching or at start, so they are visualising booting using FRC and using this sequence to start the main oscillator.

Unfortunately a lot of the newer/larger chips do show problems. This one:
<http://www.ccsinfo.com/forum/viewtopic.php?t=57256>
is a similar little 'nasty' found in the last few days.
This is one of the reasons that some of the 'old hands' will recommend sticking to slightly older generation chips. Let someone else find the bugs!...

It is very much a problem, since sometimes the combinations of features available do look so tempting.
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Fri Jun 29, 2018 8:34 am     Reply with quote

I did initially try to start with FRC, then after waking up use setup_oscillator() and a delay call, but it didn't work. That said, I didn't put in any code for the other lines in their workaround, so I didn't completely follow all the instructions. At some point, I'm gonna go back and try and do it proper to see if it actually fixes the problem.

Luckily this chip is just for our dev board, so I don't really actually need to be using sleep() on it, after all I can just emulate it on the dev board if the timing actually matters (or I can just use the FRC for development...no big temperature fluctuations usually). The workaround they posted wouldn't work for some of our more extremely low average current draw products though. We'll just use other chips for that. I still like the chip overall for its large range of peripherals and IO. It makes doing R&D very handy on a much larger range of products than we previously could tackle.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 8:57 am     Reply with quote

FYI, the 'bodge' wake up, should be:
Code:

#include <24FJ1024GB610.h>
#device ICSP=1
#use delay(internal=32000000)
//boot clock

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES CKSFSM                   //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES NOBROWNOUT               //No brownout reset
#FUSES NOJTAG                   //JTAG disabled
struct {
   byte ROSEL:4; //creates a nibble sized variable
} RO;


#BYTE RO=getenv("SFR:REFOCONL")
#BIT ROOUT=getenv("BIT:ROOUT")
#BIT ROEN=getenv("BIT:ROEN")

void main()
{
   //Now switch to the external crystal using PLL at 32MHz
   RO.ROSEL=2; //write this to the nibble at bottom of REFOCONL
   ROOUT=FALSE;
   ROEN=TRUE; //enable the reference oscillator to use POSC
   delay_ms(9); //wait for the oscillator to start and stabilise
   setup_oscillator(OSC_CRYSTAL, 32000000, 8000000); //for an 8MHz crystal
   //Hopefully at this point the primary oscillator is running and stable

   while(TRUE)
   {
      //TODO: User Code
   }
}

Obviously this 'enable' block could be made into a little routine and called when necessary to start from sleep etc.
No idea if it'll work, but it should be close to right. Smile
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group