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

Applying fix for erratum 17 80220j PIC4550

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



Joined: 11 Mar 2010
Posts: 19350

View user's profile Send private message

Applying fix for erratum 17 80220j PIC4550
PostPosted: Mon Nov 28, 2011 10:29 am     Reply with quote

Hi,
Wondering if anyone has an 'elegant' way of applying this erratum?.
Seeing a significant percentage of boards, hanging on power up, and not recovering with the watchdog. Investigation shows that the I2C peripheral is refusing to initialise properly, and once it happens, the watchdog restart won't clear it....

Switching to using software I2C, fixes the problem, but leaves me with performance issues.

The suggested fix is just to set the pins as outputs, drive them low for a moment, then set them to float, before initialising the I2C peripheral.

Want to apply the fix outlined in the errata sheet, but scratching head about how to do it without rewriting a lot of code. Problem is that the I2C initialisation code from CCS, is inserted before the main code actually starts.

Thoughts:
1) Use #build, and add the fix as a few instructions before the actual CCS code. Best currently on the table....
2) Don't use the supplied #use I2C, but instead initialise the peripheral manually after the fix. Means writing my own versions of all the I2C routines. OK, but seems more work than #1.
3) Try using two I2C initialisation lines, one for a software port, then apply the fix and have the hardware initialisation. Rather a kludge but might be workable.

So wondering if anyone else has any thoughts on an elegant way to apply this fix?.

Best Wishes
jeremiah



Joined: 20 Jul 2010
Posts: 1326

View user's profile Send private message

PostPosted: Mon Nov 28, 2011 10:48 am     Reply with quote

I don't know if it is better than the #build option, but is it feasible to disable the I2C in the main (occurs after the built in initialization from the compiler), do the stuff you need to do, and then re-enable the I2C after that?

I know that means some duplicated instructions (that is assuming this method works), but I tend to like solutions like this over preprocessor based options when I can afford it (assuming you only have to do it once in the main), at least preprocessor instructions that are compiler specific.

I am suggesting this under the assumption that disabling the I2C prior to manipulating the lines is sufficient, but I don't know for sure if that is the case.
Ttelmah



Joined: 11 Mar 2010
Posts: 19350

View user's profile Send private message

PostPosted: Mon Nov 28, 2011 10:58 am     Reply with quote

It doesn't appear to be the case. Once hung the peripheral doesn't recover till a POR. Otherwise the watchdog would recover things.

I must admit to considering option #4 at present, switching to the 18F4553. Pin compatible, identical peripherals, except for 12bit ADC, and though it has some faults, not this one!.

Pity though, since it'll mean people holding two different chips who are maintaining kit, since the 4550, is in a few dozen products already....

Best Wishes
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