Jump to content
43oh

Value line errata updated - new BCL12 workaround


Recommended Posts

Hi guys,

 

I just noticed that the errata files for the value line were updated on 17th January. The new files contain a revision to the BCL12 text, adding the following advice:

 

"In the majority of cases switching directly to intermediate RSEL steps as described above will prevent the occurrence of BCL12. However, a more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

 

Might be of interest if you've been getting DCO lockups as I have recently!
Link to post
Share on other sites

This is another errata than the one stating you should set RSEL to 0 in between?

 

Hi, I'm not sure which erratum you're describing there. BCL12 used to be:

 

1) If changing RSEL from >13 to <=12, switch to 13 first

2) If changing RSEL from <=12 to >13, switch to 7 first

3) If changing DCOCTL when RSEL is 15, set RSEL to 7, modify DCOCTL and then reset RSEL to 15

 

The updated version says that these original rules fix most cases, but a more reliable method is to always change RSEL step-by-step. By that I think they mean increment or decrement RSEL by 1 until you reach the target value.

Link to post
Share on other sites

But they do not describe in what pace, would it really be required to wait for the oscillator to stabilize (there are flag for that, right?) and then step to the next value. I mean, startup code will get quite a bit bigger now :-(

 

This is for the DCO, so there's no flag to wait for - AFAIK only the crystal oscillator has a fault flag. Normally the DCO is what's clocking the CPU, so I think changing the DCO settings makes the CPU pause until the DCO is stable. At least, that's what it does when restarting the DCO after LPM.

 

As for the effect on code size, I'm wondering whether the new advice actually simplifies things. If you just use a loop to step RSEL to the desired value then you never need worry about rules 1 and 2. On startup, rule 3 can be avoided if you set DCOCTL before ramping RSEL up to 15 (if that's what you want to do).

 

I expect the main impact will be on code that changes DCO settings after startup. If you're changing between values that aren't known at compile time you'd need a lot of extra code to check for all these different conditions.

Link to post
Share on other sites

This is for the DCO, so there's no flag to wait for - AFAIK only the crystal oscillator has a fault flag. Normally the DCO is what's clocking the CPU, so I think changing the DCO settings makes the CPU pause until the DCO is stable.

 

Having said that, maybe you're right and I do need to wait between steps so the DCO can settle. I tried the updated workaround on a problematic chip last night, and while it improved matters it didn't fully resolve the issue. I'll see if adding some delay cycles to my RSEL-stepping loop helps any.

Link to post
Share on other sites

I added some delays to the RSEL stepping loop, but it didn't help. As I was testing the change I realised that I've been stepping through the code in the debugger anyway, which gives the DCO more than enough time to settle.

 

I also tried clocking the CPU with VLO during the DCO setup. This allowed the CPU to continue running past the instruction that was previously killing it (setting RSEL to 15). Unfortunately when I then tried to switch the CPU back to DCO it hung. It looks like the bug might cause the DCO to completely stop oscillating if you're really unlucky.

Link to post
Share on other sites

What are you doing that you are messing with the DCO? I've never had a problem setting the clock or seen any glitch or hang.

 

I'm working on a program that measures the DCO clock frequency for all valid combinations of RSEL, DCO and MOD bits. 

 

It works fine on two chips I've tried it on (a 2553 and a 2001), but fails when I try it on my 2452. I suspect it's just down to tolerances in the chip, so most will work fine.

 

The problem occurs when trying to reach the higher DCOCTL settings with RSEL set to 15. Following the old BCL12 advice I was able to reach DCOCTL = 0xCF, BCSCTL1 = 0x8F, but going any higher caused a hang. The new advice lets me reach DCOCTL = 0xD7, but it should be possible to go all the way up to 0xE0.

Link to post
Share on other sites

And I've found a solution - ignore the bit of BCL12 that says if RSEL is 15 you should drop it to 7 before modifying DCOCTL (this advice conflicts with that in the user guide).

 

By following the BCL12 advice I had one chip out of four fail after clock setup. Following the user guide (as posted by Rickta59 and roadrunner84 above) caused no failures.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...