Not applicable
Jan 13, 2016
05:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
05:41 AM
Hi all,
According to the datasheet, the DCO1 oscillator frequency shall be within ±0.5 MHz (that's ±0.78%) around the nominal 64 MHz at nominal Vddc and ambient temperature (+25°C) (factory trimmed).
I have already enabled the DCO1 calibration with respect to temperature, this compensation is working as expected.
However, I am observing at many of my XMC1100 samples that the DCO1 frequency is well outside of the specification, sometimes by more than 3%.
According to this post, there was a known frequency deviation issue at the factory trimming process.
When was this issue solved ? How can I know if my parts are affected by this issue ? Is there a production code on the chips*?
One more question arises:
The temperature calibration data is stored in flash sector 0.
The factory trimming data is probably also stored in this flash sector.
According to the reference manual:
"In XMC1100, the Boot Mode Index (BMI) is used to control the boot options such that
once the BMI is programmed to enter user mode (productive), it is not allowed to enter
the other boot modes without an erase of the complete user Flash (including sector 0)."
Does this imply that after I change the BMI from "productive" back to any other boot mode, the trimming and temperature calibration data will be lost ?!
Thanks for your help
According to the datasheet, the DCO1 oscillator frequency shall be within ±0.5 MHz (that's ±0.78%) around the nominal 64 MHz at nominal Vddc and ambient temperature (+25°C) (factory trimmed).
I have already enabled the DCO1 calibration with respect to temperature, this compensation is working as expected.
However, I am observing at many of my XMC1100 samples that the DCO1 frequency is well outside of the specification, sometimes by more than 3%.
According to this post, there was a known frequency deviation issue at the factory trimming process.
When was this issue solved ? How can I know if my parts are affected by this issue ? Is there a production code on the chips*?
One more question arises:
The temperature calibration data is stored in flash sector 0.
The factory trimming data is probably also stored in this flash sector.
According to the reference manual:
"In XMC1100, the Boot Mode Index (BMI) is used to control the boot options such that
once the BMI is programmed to enter user mode (productive), it is not allowed to enter
the other boot modes without an erase of the complete user Flash (including sector 0)."
Does this imply that after I change the BMI from "productive" back to any other boot mode, the trimming and temperature calibration data will be lost ?!
Thanks for your help
1 Reply
Jan 13, 2016
09:22 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2016
09:22 PM
Hello Cedric,
The issue was fixed in mid-July 2014.
To check if the parts are affected, you have to read out a 2-byte data from the Flash config sector address 0x1000'0FEA (e.g. via the memory monitor feature in the debugger view).
For the affected devices, these bytes are 0x0000 or 0xFFFF.
Anything else will indicate that the device is okay.
Regarding the restoration of Flash with change in BMI away from user productive mode, only the main Flash will be erased.
The config sector parameters including internal trim values and calibration data are not affected.
Regards,
Min Wei
The issue was fixed in mid-July 2014.
To check if the parts are affected, you have to read out a 2-byte data from the Flash config sector address 0x1000'0FEA (e.g. via the memory monitor feature in the debugger view).
For the affected devices, these bytes are 0x0000 or 0xFFFF.
Anything else will indicate that the device is okay.
Regarding the restoration of Flash with change in BMI away from user productive mode, only the main Flash will be erased.
The config sector parameters including internal trim values and calibration data are not affected.
Regards,
Min Wei