MC9S08AW60 communication problem

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MC9S08AW60 communication problem

2,878件の閲覧回数
umedsingh
Contributor II

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.

ラベル(1)
15 返答(返信)

2,594件の閲覧回数
tonyp
Senior Contributor II

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.

0 件の賞賛
返信

2,594件の閲覧回数
david_diaz
NXP Employee
NXP Employee

Hello,

Are you using some communication protocol? What kind of protocol?

Have a great day. :smileyhappy:

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

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.

0 件の賞賛
返信

2,594件の閲覧回数
marek_neuzil
NXP Employee
NXP Employee

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

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

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?

0 件の賞賛
返信

2,594件の閲覧回数
marek_neuzil
NXP Employee
NXP Employee

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

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

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 */

  }

0 件の賞賛
返信

2,594件の閲覧回数
marek_neuzil
NXP Employee
NXP Employee

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

2,594件の閲覧回数
umedsingh
Contributor II

we are using SCI protocol and we had sent a lot of query for technical assistence to freescale

0 件の賞賛
返信

2,594件の閲覧回数
marek_neuzil
NXP Employee
NXP Employee

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

0 件の賞賛
返信

2,594件の閲覧回数
rsdio
Contributor II

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.

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

we are using SCI protocol

0 件の賞賛
返信

2,594件の閲覧回数
Martin35804
NXP Employee
NXP Employee

Hi,

-have you considered to submit technical service request @ freescale.com with details of your problem?

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

we are using SCI protocol and we had sent a lot of query for technical assistence to freescale

0 件の賞賛
返信

2,594件の閲覧回数
umedsingh
Contributor II

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.

0 件の賞賛
返信