we are using MC9S08AW60 microcontroller in one of our product, we are facing communication problem in 60% failed in every lot, if anyone had solution for this type of problem, please support us, freescale does not supporting us.
As Marek has already mentioned, for the trim value to work correctly, two things must happen:
1. Your programming tool calculates a trim value and stores it in the appropriate Flash location during loading of your application into Flash.
2. Your code actually copies the trim value from its non-volatile location to the related register during soon after reset (i.e., before you need to depend on this frequency being accurate enough).
If both of these steps are correctly performed, and you're still having problems, then most likely your assumption about the trimmed bus frequency is wrong. How could this happen? For example, P&E programming algorithms use a default bus frequency for each MCU variant. If your app uses a different one (which in my experience is very common), you need to also adjust the related programming algorithm so that the trim value is calculated correctly. (How to do that is a different matter as there is not clear documentation on this, at least with older versions of their software. But if this is the problem you're having, ask again.)
A USBDM-based programmer, on the other hand, will allow you to set the trim frequency directly.
Hello,
Are you using some communication protocol? What kind of protocol?
Have a great day. :smileyhappy:
Dear,
We are using MC9S08AW60 microcontroller in one of our standard product SMOKEMETER from last one year.
We are using USART1 of microcontroller for PC interface.
In some cards . we found that microcontroller is not giving data to PC(hyper terminal).
Then we use demo board , supplied from freescale to check our hardware and then check with microcontroller and after this exercise we found that approx.. 50 to 60 microcontrollers out of 100 are not giving data to PC.
Now question is that same software and hardware act differently from microcontroller to microcontroller?
Is this microcontroller behavior or something else?
In short I want to clear that we use microcontroller in self clocked mode.
Please do needful ASAP , we can give live demo to you also.
This problem has stucked our production.
Hello,
If you use the self clocked mode (without any external crystal) and the internal oscillator is not properly trimmed the SCI baudrate can be different and the communication failed. There is trim value of the internal oscillator stored in non-volatile memory. This trim value can be used for proper internal oscillator configuration (ICGTRM register value). Do you initialize the ICGTRM register by this NVM value?
Best Regards,
Marek Neuzil
hello,
thanks for prompt response.
We are using MC9S08AW60 in self clock mode with below setting
ICGC1 = 0x44;
/* ICGC2: LOLRE=0,MFD2=0,MFD1=0,MFD0=0,LOCRE=0,RFD2=0,RFD1=0,RFD0=0 */
ICGC2 = 0x00;
/* Common initialization of the write once registers */
now we want to set ICGTRM register but it is byte and value can vary from 0 to 255, how we set trim value?
Hello,
the trimmed value is stored in NVM at address $FFBE address, for example see the Table 4-4. Nonvolatile Register Summary in MC9S08AW60 Data Sheet, Rev 2. See also the datasheet for additional information how to set and use the NVM trim value.
You can use for example following initialization code for ICGTRM in your application:
if (*(uint8_t*)0xFFBEU != 0xFFU) { /* Test if the device trim value is stored on the specified address */
ICGTRM = *(uint8_t*)0xFFBEU; /* Initialize ICGTRM register from a non volatile memory */
}
This fragment of the source code is generated by Processor Expert CPU driver for MC9S08AW60 derivative in CW MCU 10.6.3.
Best Rergards,
Marek Neuzil
hello,
we use this piec of code but problem is remaining same
if (*(byte*)0xFFBEU != 0xFF) { /* Test if the device trim value is stored on the specified address */
ICGTRM = *(byte*)0xFFBEU; /* Initialize ICGTRM register from a non volatile memory */
}
Hello,
I am sorry but you must analyze the problem. Have you checked the SCI baudrate of boards that do not communicate with PC (is there any communication)? Is the issue caused by incorrect settings of the internal oscillator? Is the NVM trimming value set by the debugger or programming tool?
I am not able to analyze the cause of your issue without your application, tools and boards. I can just provide my experience and knowledge based on your description of the problem.
Best Regards,
Marek Neuzil
Hello,
I have not enough technical details about your issue but the SCI communication is very sensitive for the precise baudrate settings. For example, your issue can be caused by using internal oscillator of the MC9S08AW60 derivative. If the internal oscillator is not precisely trimmed the SCI baudrate can be different and communication failed (usually indicated as a frame error).
There can be also many other issues that caused the problem (incorrect SCI driver - e.g. overrun error).
Do you use CodeWarrior 10.6 and Processor Expert? There is available AsynchroSerial component that provides a SCI driver.
Best Regards,
Marek Neuzil
Could you provide more information? What device is connected to the other end of the MC9S08AW60 SPI port? Do you have more than two devices on your SPI bus? Which SPI mode are you using: 0, 1, 2, 3? What is your clock rate? What is your word depth? Perhaps the requirements of the other devices on your SPI bus do not match your settings.
Hi,
-have you considered to submit technical service request @ freescale.com with details of your problem?
Dear,
We are using MC9S08AW60 microcontroller in one of our standard product SMOKEMETER from last one year.
We are using USART1 of microcontroller for PC interface.
In some cards . we found that microcontroller is not giving data to PC(hyper terminal).
Then we use demo board , supplied from freescale to check our hardware and then check with microcontroller and after this exercise we found that approx.. 50 to 60 microcontrollers out of 100 are not giving data to PC.
Now question is that same software and hardware act differently from microcontroller to microcontroller?
Is this microcontroller behavior or something else?
In short I want to clear that we use microcontroller in self clocked mode.
Please do needful ASAP , we can give live demo to you also.
This problem has stucked our production.