Moving from ICE to stand alone target problems.

[erokc]

I am having problems getting the target to run on its own.  My first attempt had the bus speed so slow I thought it had locked up until a couple of minutes later it responded to my previous input.

Back to the FSICEBASE.  The Code Warrior Target Settings were used to get the correct bus speed during emulation but the CGM needed correct setting. The Clock Generator Module was not set up correctly.  I found a procedure error and changed it to try getting the PLL and source selected.  That caused the IIC devices to not work.  Also the PLL LOCK never went true.  I don't know if the CGM is suposed to work within the ICE.

Another related issue is getting the target FLASH erased for loading new a program.  The monitor erase function needs to know the bus speed.  Until I can establish what that is I can't write an erase routine.

I am using the serial connection described in the HC908AP data sheet in the Monitor section.  PROG08AZ program works to program the FLASH but it will not access the monitor if the reset vector is not $FFFF.  There is an on board oscillator (32 kHz)driving the OSC1 pin.  No means to apply Vpp.  I need to be able to have the target program erase FLASH.

I need to get the correct bus speed established.

I need to write an erase routine that looks for a port input upon POR.

Where should I start?  BTW, I program in assembly.  I can usually read C.  Here is my CGM set up.  Do you see a problem?

      SEI

       CLR  PTCL  PLLON = 0  P = 0  E = 0

       LDA  #$80    AUTO = 1

       STA  PBWC

       LDA  #$F5    N = $00F5

       STA  PMSL

       LDA  #$40     L = $40

       STA  PMRS

       LDA  #$01     R = 1

       STA  PMDS

       LDA  #%00100000  PLLON = 1

       STA  PTCL

       LDA  #%00110000   BCS = 1

       STA  PTCL

Please help.

Dave

[erokc]

Well, having to continue with the project I modified the target board that needed erasing and was successful in bringing it up in monitor mode.

I discovered I needed to wait for the PLL to LOCK before setting BCS.  I did that and it works, almost.  The bus speed seems to be double what it should be.  I'm going by software delay loops I use in flashing the display.  I will take another look at the settings.  I'm sure the data sheet can't be wrong!

As for erasing the FLASH, it didn't work from the user program.  It should be so simple.  Maybe the fast bus speed prevented the erasure because ERARNGE was set for half the apparent bus speed.

Dave

[erokc]

OK, I changed a divisor (R) from 1 to 2 and now the bus speed is what I expected.  What bothers me is I don't know why it was wrong to begin with and will the fix not be stable or otherwise come back on me.

As for erasing FLASH, it still doesn't work.  I appears to reset the CPU instead of erasing memory.  Are the ROM routines available in user mode?  The data sheet says "yes".  When I try to read the ROM locations with PROG08SZ it shows "U" in the memory location.  Should that memory be readable?

Still don't understand!  Might as well be talking to myself!

Dave

[bigmac]

Hello Dave,

You do not specifically mention, but I assume that your target is actually the 908AP64, and not the 908AP64A.  The PLL reference frequency of the latter is not compatible with 32.768kHz source.

You also do not say what your bus frequency expectation was - is this approximately 2MHz?

The ROM routines are available from within user code, but you should check out the Mask Set Errata documents for the device, because of erase problems with some masks.  However, my understanding is that this would affect block erase, and not mass erase.

It is quite possible that PROG08SZ utility would not display the ROM locations, since this is outside the flash range for the device.

How do you know that the flash erase doesn't work?  I assume that you are unable to enter monitor mode, and that the original program remains operational.  I would suggest that you provide the Vtst voltage, at least for the prototype board, and this will enable you to enter monitor mode for debug purposes.  This is important when making use of the ROM routines, since it is not possible to test using the emulator.

Regards,

Mac

[erokc]

Hello Mac,

You have helped me before and I am truly grateful.  I have spent most of a week trying to get past clock speed setting and mass erasing FLASH.

I have found the problem with the mass erase.  The FLASH block protection is not mentioned once in the monitor routines.  I knew the erase was not happening because the program continued to run afterwards.  I knew the code ran because I moved my I/O detect and LED output code to RAM and it completed by turning on the LED.  I started to suspect some kind of protection so I searched for FLASH in the document and found it in the Memory section.

I did modify a board to use the Vtst method so I could erase it.  I now can have it erase itself by grounding one of the I/O pins on POR.  I plan to back up the RAM into FLASH so when the battery is replaced it will have good data afterwards.  I would use the page erase and write functions.  I'll be writing that later.

Yes, I'm using a non A, 908AP16.  About the bus speed. I have a separate 32 kHz oscillator feeding OSC1.  I used the values from the table to set the VCO and PLL for 2 MHz, top line of table.  I have not measured the bus speed but will do so.  My observation is the software delay loops are about half what they should be.  I changed the R value from 1 to 2.  It now seems to have the proper delay.  This bothers me to leave it as I don't know why it didn't work by the table.  I don't want a half fix that might cause a problem later like instability in the PLL.

What is the easiest way to measure the bus speed?  I have instruments, I just need a signal.  I thought of setting the Timebase Module and toggling an I/O pin to see if it was the correct frequency.  Well that won't work.  It's clock source is the OSC Module, not the PLL.  OK, how about a short software loop that toggles a pin. I count the cycles to arrive at a delay time and compare to measured.

I would like to check the Mask Set Errata document.  Where do I find it?

Thanks, Dave

[bigmac]

Hello Dave,

---

erokc wrote:

I have found the problem with the mass erase.  The FLASH block protection is not mentioned once in the monitor routines.  I knew the erase was not happening because the program continued to run afterwards.  I knew the code ran because I moved my I/O detect and LED output code to RAM and it completed by turning on the LED.  I started to suspect some kind of protection so I searched for FLASH in the document and found it in the Memory section.

---

I assume you now set the FLBPR register to a value of $FF prior to calling the erase routine, and that you can now successfully mass erase the device.

---

What is the easiest way to measure the bus speed?  I have instruments, I just need a signal.  I thought of setting the Timebase Module and toggling an I/O pin to see if it was the correct frequency.  Well that won't work.  It's clock source is the OSC Module, not the PLL.  OK, how about a short software loop that toggles a pin. I count the cycles to arrive at a delay time and compare to measured.

---

Another method of measuring bus speed is using the TIM.  Perhaps toggle a pin within the overflow ISR.  The period between each toggle will depend on the TMOD value and the prescale setting.  For default TMOD value ($FFFF) and prescale of 1, the period should be about 32.8 ms between each toggle, i.e. for each half period of the square wave output.

---

I would like to check the Mask Set Errata document.  Where do I find it?

---

I would normally use the "Products" menu item on the FS web site, and narrow down to the particular device I required.  Any MSEs should be found, along with the data sheet document.  Alternatively, you could use the search engine - the one for the FS website, and not the one for the forums.  But there are currently problems using the FS search engine from the forum web pages.

Regards,

Mac

[erokc]

Hello Mac,

I found the Errata sheet and put a copy with the data sheet. I supose I should check the next purchase of product to see if the mask is different.  I was not aware of the existance of the Mask Set Errata.  Thank you for bringing it up.  There are no real problems related to my product.

I checked the bus speed.  It is running according to the CGM table data so I decided to check my DELAY loop.  The original product used HC05 and two of the instructions in it have less cycles on the HC08.  That's the problem, not the bus speed.  Easy fix, NOP, NOP ....!  The HC08 does NOTHING faster than the HC05!

I work alone and don't have anyone to bounce ideas and problems off of.  You folks on the Forum are invaluable to me.  Keep up the good work.  Maybe some day I will have enough knowledge to contribute.  In the mean time I'll buy more Freescale controllers.

Regards,

Dave