8-bit MicrocontrollersのトピックRe: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Mon, 06 Jun 2011 22:15:42 GMT

Hello friends, I have a problem to obtain an exact 1 millisecond flag using the MTIM module.

Here are the details:

USBSPYDER08 programmer ( trimming enabled 20000000 DCO )

A very simple program in C using CodeWarrior 6.2

Device initialization wizard screen shows:

CPU:

Internal oscillator frequency = 31.25 KHz

Initialize trim values = Yes

Trim value address = 3FFA

Fine trim value address = 3FFB

Bus freq. divider = autoselect

Internal bus clock = 8.0 MHz

FLL = Engaged

MTIM settings:

Clock source = bus clock

Prescaler = 32

Modulo register value = 249

Period = 1ms

Overflow interrupt = disabled

Enable MTIM module = Yes

Main program code:

void
main(void)
{
    MCU_init();

    for( ; ; )
    {
        while( MTIMSC_TOF == 0 ) /* wait for MTIM counter overflow */
            ;
        MTIMSC_TOF = 0;    /* clear counter overflow flag */

TEST_PIN ^= 1; /* oscilloscope mark 500 Hz square wave */

timer_tick(); /* really small processing here */
}
}

MCU_init() contains this code that installs trimming values in corresponding registers:

/* System clock initialization */
ICSTRM = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFA); /* Initialize ICSTRM register from a non volatile memory */
ICSSC = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFB); /* Initialize ICSSC register from a non volatile memory */
/* ICSC1: CLKS=0,IREFSTEN=0 */
ICSC1 = 0x00; /* Initialization of the ICS control register 1 */
/* ICSC2: BDIV=0,LP=0 */
ICSC2 = 0x00;

/*---------------------------------------------------------*/

The result is a 800 us ( 0,8 ms ) MTIM overflow instead of 1000 us ( 1 ms ) period.

I can see that the USBSPYDER writes "Trimming ... " while in FLASH programing.

I can't understand what I am doing wrong. This has worked for me with any other 9S08 MPU perfectly well.

Any ideas ?

Thank you in advance.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

Mickey — Mon, 06 Jun 2011 22:33:59 GMT

Hi, I think it was trimming problem, you can replace the P&E multilink/cyclone pro/ USBDM, download s19 file only.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Mon, 06 Jun 2011 23:45:58 GMT

Mickey thank you fo your return. I really want to know what is going on because I need to put this chip into production.

The only way I have to program this device right now is the USBSPYDER08. Then, I have a DEMOQE128 board that allows me to program many other chips of this family but not the KA2.

Correct me if I'm wrong but what you mean is that the code ( s19 file ) is correct and the device or something in the programming chain is failing to trim ? So it would be nice to program the chip just with the s19 file. If so, I beleive that too. I will reinstall the PC driver for the USBSPYDER08 to see if I have something wrong there.

I don't think that the CW tool is failing from the initialization wizard's point of view. I've been using this tool for a long time with many different family chips with no problems. I will also check if the USBSPYDER08 programmer generates a log file with the trimming values used for FLASH programming. I tested some 10 brand new chips and I am getting exactly the same result, so I am starting to think that the FLASHed trimming values are wrong.

Kind regards

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

bigmac — Tue, 07 Jun 2011 00:47:19 GMT

Hello BB,

I tend to agree with Mickey on the likelihood that the non-volatile trim value at address 0x3FFA is not being programmed. This can easily be directly ascertained during debug. The unprogrammed value of 0xFF will result in a very low oscillator frequency,

The trim value cannot be included within your S19 file because it will be subject to unit-to-unit variation to allow for production tolerances. If the Spyder is not capable of calibrating the trim, you may need to use a USB Multilink, which does have this capability.

It may be worthwhile for your code to provide a "sanity check" so that a specific indication is given (such as continuous flashing LED), should the non-volatile trim register be unprogrammed. If detected during final test, this might prevent a faulty product from reach the field.

Regards,

Mac

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Tue, 07 Jun 2011 01:09:56 GMT

Hello bigmac, I understand what you mean and I agree completely. With one of my friends and colleague we bought 2 units USBSPYDER08 2 years ago from a local Freescale rep here in Buenos Aires, and we have been programming and trimming with no problems. I will check the trimming FLASH cells to see if they have FF. I will report the results. It would be nice to ask somebody at Softec Microsystems ( the SPYDER's manufacturer ) if they have some reference of this problem. I have stock of about 500 pcs of this chips that I bought from Mouser and I believe they should be OK. The mask marked on the chips is ZRWY 0912.

I will keep on trying.

Thank you.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Tue, 07 Jun 2011 01:47:35 GMT

Okay dear friends, here are some results:

6 brand new chips from the box, programmed with the same USBSPYDE08 device showed some nice expected results when looking at the FLASH memory map after entering debug memory addresses $3FFA and $3FFB :

Chip # 1 = 61 01

Chip # 2 = 5C 01

Chip # 3 = 64 00

Chip # 4 = 5A 00

Chip # 5 = 6C 00

Chip # 6 = 5D 00

The same chips have been re-checked without programming (just verifying) and the same exact values are still there in FLASH.

So the clock is being correctly trimmed ( hope so ) and the FLASH memory is being correctly programmed as seen.

After this I am copying a portion of the wizard's generated code in assembler. Highlighted in green, I can see that the code is initializing the trimming registers. Do you agree that this is the correct code to do this ? I believe yes.

If this is OK, the only thing that may be causing the failure is that this code is not being excecuted, but I discard this possibility. Many things are working fine in the chip, MTIM, modulo counter value, etc. Besides this I could alter the divisor and I can see the frequency change.

   40: ** ==============================
   41: **     Method      : MCU_init (bean MC9RS08KA2_6)
   43: **     Description :
   44: **     Device initialization code for selected peripherals.
   45: ** ==============================
   46: */
   47: void MCU_init(void)
   48: {
         *** EVALUATION ***

   49:    /* ### MC9RS08KA2_6 "Cpu" init code ... */
   50:    /* PE initialization code after reset */
   51:    /* Common initialization of the write once registers */
   52:    /* SOPT: COPE=0,COPT=1,STOPE=0,BKGDPE=0,RSTPE=0 */
   53:    SOPT = 0x40;
0000 3e001f           MOV        #%HIGH_6_13(_SOPT),PAGESEL
0003 3e4000           MOV        #64,%MAP_ADDR_6(_SOPT)
   54:    /* SPMSC1: LVDF=0,LVDACK=0,LVDIE=0,LVDRE=1,LVDSE=1,LVDE=1,BGBE=1 */
   55:    SPMSC1 = 0x1D;
0006 3e1d00           MOV        #29,%MAP_ADDR_6(_SPMSC1)
   56:    /* System clock initialization */
   57:    ICSTRM = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFA); /* Initialize ICSTRM register from a non volatile memory */
0009 3eff1f           MOV        #255,PAGESEL
000c 4efa00           MOV        250,_ICSTRM
   58:    ICSSC = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFB); /* Initialize ICSSC register from a non volatile memory */
000f 4efb00           MOV        251,_ICSSC
   59:    /* ICSC1: CLKS=0,IREFSTEN=0 */
   60:    ICSC1 = 0x00;                        /* Initialization of the ICS control register 1 */

etc, etc, etc, ....

0012 80 CLR _ICSC1

002f be RTS 

/-----------------------------------------------------------/

Really lost and confused ...

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Wed, 08 Jun 2011 07:53:16 GMT

Friends, please, I need your opinion:

This portion of code that follows, was taken from AN3471 "Ceiling Fan Speed Control
Single-Phase Motor Speed Control Using MC9RS08KA2"

Comparing the code generated by CodeWarrior Initialization wizard that I posted before ( assembler highlighted in green ), and this portion of code below, I don't see the loop that "Waits until FLL is engaged" after the clock source is selected.

My question is: is this OK ? Could this be the reason for the trimmimg failure ?

I really need to know why my chips are not working. I hope this could be the reason.

Kind regards.

/**********************************************************/

;CONFIGURES CLOCK (FEI Operation Mode)
    mov #HIGH_6_13(NV_ICSTRM),PAGESEL
    lda MAP_ADDR_6(NV_ICSTRM
       sta ICSTRM                      ; Sets trimming value
          clr ICSC1                    ; Selects FLL as clock source and disables it
                                       ; in stop mode
          clr ICSC2                    ; ICSOUT = DCO output frequency
wait_clock:
    brset CLKST,ICSSC,wait_clock       ; Waits until FLL is engaged

/*********************************************************/

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

Mickey — Wed, 08 Jun 2011 08:29:59 GMT

Attached is my ka2 template, if the trim is 31.25KHz, PTA0 the output will be 500Hz.

If not 500Hz, then I think you should replace a debugger and try again.

I DIY a KA2 standalone programmer, you interested? It can not rely on PC, automatic calibration and download, suitable for use in mass production.

I already have a P&E Cyclone pro, but it still can not meet my needs.

My demand is to every one of the RTC error value KA2 stored at a certain address, and to avoid sleep problems when the time is not accurate, currently this standalone programmer to solve my problem.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Thu, 09 Jun 2011 00:39:42 GMT

Mickey, here are the results and some comments about this problem. I programmed a brand new KA2 with your S19 template. You can see the square wave from the attachment. It is 634 Hz and not 500 Hz. That probes that something is still very wrong this end.

It would be nice to have your source file to see if the FLL wait loop was included or not. Could you please send this initialization code so we can compare it to both the application note's and the CodeWarrior generated one ?

As a comment, I used 2 different programming tools: the USBSPYDER08 and the DEMOQE board. The results are identical. After programming an testing with each of the programmers, I checked for the FLASH locations containing the trimming values. In both cases the values are identical.

If we could see your template's software ( which I believe is OK and it works for you at exactly 500 Hz ) we could see what is needed for the chip to work fine ( calibrated ).

My next step is to force a constant value into the trimming registers to see if the chip reacts to this change ( square wave frequency ). If it does, my next suspect will be the PC itself or the software driver. If both programming boards reach the same trimming value results, then the chip's internal uncalibrated frequency is being wrongly measured for some reason.

I am using this same DEMOQE board to program lots of other chips ( QE8, QG8, etc ) with no problems at all.

So Mickey please provide me this information so we can compare codes.

Kind regards

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Thu, 09 Jun 2011 03:32:04 GMT

More results:

1. including the wait loop into the initialization code didn't worked. For the current clock needed wizard settings this loop makes the processor hang because this bit never gets set.

2. I tried manually forcing different values of ICSTRM and I could finally obtain the 1 ms ( 1000 us ) MTIM period using the debugger. This means than the calibration internal registers are working fine. Going up and down with the values returned reasonable consistent period results. This is a fragment of the initializing code with values that work:

ICSTRM = 0xA6; /* forcing these values produce the correct 1 ms period for MTIM OVF */
ICSSC = 1;
/* commented original code:
ICSTRM = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFA);
ICSSC = *(unsigned char* __paged)CONVERT_TO_PAGED(0x3FFB);
*/

3. correct me if I'm wrong, but it seems that the calibration values obtained from the USBSPYDER08 and the DEMOQE board for this chip, are wrong. $A6 against $5B. Quite a difference.

4. I moved the complete programming session to a different machine, installed a fresh version of the compiler and drivers, tested, and the result was the same. Wrong ( same ) trimming values in FLASH.

Next step is consulting FREESCALE technical support and Softec Microsystems. Big problem not solved son far.

Cheers

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

bigmac — Thu, 09 Jun 2011 21:28:46 GMT

Hello BB,

Here are a few points for consideration:

The calibration process, and the programming of address 0x3FFA, should be totally independent of any application code programmed to the device.
For FEI operation, I would expect the lock wait loop to be unnecessary in most instances (even though Processor Expert device initialisation does include the loop). This is because FEI is the default mode of operation, and FLL lock should occur within 1 ms of the ICSTRM register being updated. The only reason I can see for lock to fail would be if an extreme calibration value (approaching 0x00 or 0xFF) were loaded to ICSTRM, such that the normal DCO frequency range was exceeded.
From the datasheet, the trim range for the reference period of 24us to 40us may be derived. A reference frequency of 31.25kHz corresponds to a period of 32us, the arithmetic mean of the above range. Therefore, nominal calibration value should be 0x80, but subject to a unit-to-unit tolerance. Since variation of the ICSTRM value will result in a linear variation of the period, each increment should result in a change of about 63ns, i.e. a frequency change of 61Hz at 31.25kHz (~0.2%).
The range of calibration values 0x5A to 0x6C seems rather low, unless the particular MCU batch you tested had untrimmed reference frequency consistently below the nominal frequency. You can check this by checking the test code output frequency with a trim value of 0x80. For the device with an experimentally derived value of 0xA6, the untrimmed frequency would be above the nominal value.

Do you use CW in conjunction with Spyder? Maybe the reference calibration method associated with CW debugger (P & E compatible) is not compatible with Spyder hardware. This seems the only explanation.

Regards,

Mac

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Thu, 09 Jun 2011 23:36:47 GMT

Thank you so much dear Mac for your kind reply.

Just to order a little this conversation just in the case some more friends are reading out there:

1. I've been using my DEMOQE board to program many chips with accurate timing tasks, such as QE128, QE8, QG8, and the like. Never had a problem. The PC, the CodeWarrior IDE, the calibration and programming tasks work perfectly well.

2. the USBSPYDER08 we bought here was intended just for KA2 chips. The tool programs the FLASH and verifies correctly. It fails to obtain the calibration values needed to be written in FLASH at locations $3FFA and $3FFB.

3. I am completely aware that the FLASHing process and the calibration process are completely separated issues. In fact, FLASHing is not the problem.

4. I understand that there may be some "typical" ranged, values for trimming, being $80 right in the middle of the scale, and that is not likely to trim with $00 or $FF. But IMHO $A0 could be a good value for a lot of chips of the same production mask. Writing this value "by hand" forcing a constant into the register, works and places the clock in the desired value. So all chips are working and accept calibration. The calibration tool should find this value correctly, as I do it by hand.

5. this tool USBSPYDER08 has apparently been discontinued and I couldn't find any support for it, no drivers downloads, no mentions in the manufacturers website Softec Microsystems http://www.softecmicro.com/ which is now SMH Technologies. Not even at the Freescale site http://www.freescale.com/webapp/search/Serp.jsp?qt=USBSPYDER08&Go=%C2%A0&QueryText=USBSPYDER08&baseUrl=http%3A%2F%2Fwww.freescale.com%2Fwebapp&PART_NUMBER=&SEARCH_OPERATOR=Contains&attempt=-1

6. please note this: the same DEMOQE board that I successfully use with the other chips, communicates perfectly with CW IDE and its Hiware software tool. Further more, it recognizes the 9RS08Kxx derivatives. Also fails to calculate de trimming values for the KA2 and throws the same bogus results the USBSPYDER08 finds.

7. same hardware and software fail to calibrate on different PC's

9. Question 1: could Softec Microsystems have released a tool not matching Freescale CodeWarrior's IDE ?

10. Question 2: what are you guy using to RELIABLY program a KA2 chip ? P&E ? Please enlighten me about this because I am about to buy a 3rd tool to get the job done and avoid making my friend here and myself loose their time

I will very much appreciate any idea to solve the problem, specially from Softec Microsystems.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

JimDon — Fri, 10 Jun 2011 02:12:14 GMT

Bob,

In theory the DEMOQE board is only designed to work with the QE. Anything else you got is a bonus.

I would ask P&E specifically if the MULTILINK will trim RS08 devices.

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

BooleanBob — Sat, 11 Jun 2011 05:34:47 GMT

Dear Jim, thank you for your opinion.

When I bought the five units DEMOQE for my lab about 3 years ago, nobody told me that the 6 pins BDM connector provided on the boards were a bonus. I don't know any document explainig this point I don't see the point in restricting this posibility. In the other hand, clearly the reason is that P&E wants to sell BDM cables, but I find this policy tricky. We have discussed this point some time ago in a different post. I have longly paid this cable by buying 5 units DEMOQE

The guys at support@softecmicro.com ( Softec Microsystems ) are not replying to my request for the USBSPYDER08 device. I will never buy anything from them in the future because in my opinion support is everything after sales. So far, I am not having support of any kind. The device bought from an authorized Freescale dealer has been discontinued and all information related to it, dissapeared. It is noticeable that the corporate mailer rejects all of my support request messages posted at their website (qota exceeded). I can provide the copies of these messages.

Instead, I received an extremely fast response from P&E Micro. They explained that the DEMOQE board is not intended for programming any other chip different from a QE128 with the same pin count as the one that comes provided with the board. However, they said that if my instalation and Codewarrior IDE is able to program almost any derivative 9S08 as I'd been doing for the last 3 years, there is a detail to be considered in the case of KA2: the trimming frequency, which is by default ~39 Khz as shown in the Hiwave screen at the moment of programming, should be custom set at 31,25 KHz ( something I didn't imagined or considered ). When I tryied this option, I couldn't FLASH the part because of a software restriction or bug related to the connection between the Codewarrior IDE and the DEMOQE board, specifically for the KAx derivatives. But to my surprise, the log file ( the screen showing all commands ) showed that the calculation of the trimming value was finally correct with $A6. So, if the DEMOQE board could have FLASHed the part, my problem should had been finally solved.

The USBSPYDER08 could never calculate the correct value, so it is perfectly normal that the part is incorrectly calibrated.

Finally, there is no solution for my problem with the elements I have handy. I am now buying a MULTILINK UNIVERSAL BDM device from P&E Micro. I believe that this tool allows programming and calibration of the complete family of derivatives.

Kind regards

Re: MC9RS08KA2CPC PROBLEM TRIMMING CLOCK FREQUENCY

Mickey — Sat, 11 Jun 2011 08:02:46 GMT

My experience tells me, USBDM the calibration accuracy better than the P&E.