Hi,
How can I understand what all Errata's are applicable to softdevice and are taken care of?
For my application I am aware of the modules/peripherals being used and the erratas can be linked/matched.
Hi,
How can I understand what all Errata's are applicable to softdevice and are taken care of?
For my application I am aware of the modules/peripherals being used and the erratas can be linked/matched.
Absolutely, I fully understand. Let me know if there should be any more questions, any time!
Thanks Karl for the help and looking into it.
I have question related to Errata 68.
The Errata workaround says
" the software must ensure, using a timer, that the crystal has had enough time to start up before using peripherals that require the HFXO."
1. How can I use the timer until the crystal has started?
2. Is there any sample code or solution for this errata?
Thanks,
Justin
Justin said:Thanks Karl for the help and looking into it.
No problem at all, I am happy to help.
Justin said:1. How can I use the timer until the crystal has started?
You are able to use the timer(trigger on rising and falling edges) at any time, but all crystals have a transient period during startup before their frequencies are stable.
Are you familiar with this? In essence, during this startup period the frequency of the oscillation is not constant, which quickly leads to trouble if you attempt to use it during this time.
The errata concerns the possibility to receive the EVENTS_HFCLKSTARTED event before the crystal is stable. It would therefore be a problem if you have a crystal with a long startup time, while your code starts executing at the beginning of this received event.
Does this clarify things?
Justin said:2. Is there any sample code or solution for this errata?
There is no official example code for this, but the solution is as stated in the workaround. First, you will need to find the worst-case startup time for your crystal. This should be documented in the crystals datasheet. If the worst-case startup time is shorter than 400 µs, no further action is required.
If the worst-case startup time is longer than 400 µs, then you need to ensure that the worst-case startup time has passed, before you start using components that rely on the HFCLK, such as the radio. You may do this using an internal timer.
Best regards,
Karl
Justin said:Thanks Karl for the help and looking into it.
No problem at all, I am happy to help.
Justin said:1. How can I use the timer until the crystal has started?
You are able to use the timer(trigger on rising and falling edges) at any time, but all crystals have a transient period during startup before their frequencies are stable.
Are you familiar with this? In essence, during this startup period the frequency of the oscillation is not constant, which quickly leads to trouble if you attempt to use it during this time.
The errata concerns the possibility to receive the EVENTS_HFCLKSTARTED event before the crystal is stable. It would therefore be a problem if you have a crystal with a long startup time, while your code starts executing at the beginning of this received event.
Does this clarify things?
Justin said:2. Is there any sample code or solution for this errata?
There is no official example code for this, but the solution is as stated in the workaround. First, you will need to find the worst-case startup time for your crystal. This should be documented in the crystals datasheet. If the worst-case startup time is shorter than 400 µs, no further action is required.
If the worst-case startup time is longer than 400 µs, then you need to ensure that the worst-case startup time has passed, before you start using components that rely on the HFCLK, such as the radio. You may do this using an internal timer.
Best regards,
Karl
Thanks Karl for all your help.