Ciao to every body,
May any body knows anythings about 9S08AW USBBDM trimming?:
Try this:
CW5.0 with ProcExp.
9S08AW derivative
Internal trimm initialized
Internal oscillator
FLL engaged
Bus speed 10MHz
SCI bean:
9600 baud.
what you will find is that 9600 baud has at least 20% speed error.
This is why the USBBDM (Pemicro tool) and/or CW didn't make any trimming
--> FFBE=FF....and OSCTRIM =FF.
Do you know it?
Do you have any suggestion?
Have a good day
Franco
Hello Jingbo,
The versions of CW6.1 and higher allow you to set internal clock frequency that you would like to trim device to. This setting can be configured in the connection assistant as you try to establish communication with the device. Once the frequency is set, the Codewarrior in conjunction with P&E hardware interface (USB ML 12/Cyclone Pro) will calculate trim value with accuracy of .2% of the center frequency and program it into Non Volatile Memory registers that are dedicated to storing Trim values. It is left up to the user to copy these values into ICSTRM register of your device upon startup.
There is no mathematical equation to calculate the trim on 9S08 device, since the actual untrimmed bus frequency varies within +-20% of the center frequency specified in the manual.
Best Regards,
Zahar
P&E
jingbo, continuing with what Zahar said, here is some code I have used to implement what he suggests. On the AW60:
ICGTRM = *(unsigned char*)0xFFBE; // Initialize ICGTRM register from non volatile memory
On the QG8:
volatile byte NV_FTRIM_INIT @0x0000FFAE;volatile byte NV_ICSTRM_INIT @0x0000FFAF; // instantiate the nonvolatile ICS Trim RegisterICSTRM = NV_ICSTRM_INIT; // load trim value if location not blank
I should note that this method works as described for my QG8 demo board, although it is still not quite working for my AW60 demo board. With the AW60, I get miscellaneous garbage characters in my serial port terminal, as if the baud timing isn't quite right.
I can add another small information piece on this matter. I do not know if pertinent...
I made only experimental sessions with DEMO9S08AW60 board and Codewarrior 3.1 with all the latest upgrades. I preferred version 3.1 instead of more recent ver. 5 (which is that supplied with the board) because of a better familiarity with this version: the newer version seams to have changed some auxiliary file like .prm etc.
I work only in Assembler: I am not familiar with C. First of all I edited the former "MC9s08aw60.inc" to a reduced format (I can't approve a 145kB initial declarations for an 8 bit processor). After this the programs work pretty well when I succeed to load them in flash. In fact this is not guaranteed: 2 out of 3 times the Codewarrior Real Time debugger fails to load the assembly code on the flash memory with the P&E debugger module.
I thought this could be related to the early version I use, instead of the newer ver. 5. The simptoms seem to indicate some difficulties to synchronize the baud rate.
In my programs I started copying the $FFBE location into ICGTRM supposing either Freescale or programmer module would have trimmed this variable. I was wrong: $FFBE was blank ($FF) and writing this value to the ICGTRM was bad. Loading default midscale value ($80) gave instead a pretty accurate result for timing.
Obviously even in a small production quantity it is impractical to trim the internal oscillator by experiments... Now I ask:
1) Is there anyone who has the same difficulties as mine to get in contact with the DEMO9S08AW60 board?
2) Is there a simple automated metode to trim the ICGTRM or the default location $FFBE during the code flashing with this board and Codewarrior?
Bye, Encoder
Encoder -
Other 08 and S08 parts with trimmable internal oscillators do automatically perform a trim calculation and store the value into a flash location during programming with CodeWarrior and the P&E Multlink or Cyclone Pro. The value in flash then must be copied to the trim register by the user's software during initalization.
We are trying to track down why this has been disabled for the 9S08QW60. I'll let everyone know when I get an answer to this.
- Rocky
Hi franco,
Here's the official "solution" straight from the horses mouth, Mark Cukier of P&E Microsystems:
"For the intial release of these algorithms, we commented out the trim. However, individual users are free to uncomment the trim lines (the three commented lines) to enable trim for their systems."
Didn't really get an answer as to why, but anyway.....
Regards Peg
Hi everybody!
I'm confused! I have two hw of the same products with AC32 onboard.
what i need is to use the load application mode in hi wave, i have a s19 with bootloader and appfile together, is it possible to trim automatically the micro with this mode? my s19 file is the dump of memory from 0x8000 to 0xfff.
How can i port the same file among more boards without bdm??
Help!
Hello,
If you are using the internal clock you generally need a custom value for the trim. For this reason you can't use an "image" that you simply drop into different devices. You still need to customise the trim value. You don't NEED a BDM but it is the easiest most reliable way to get it done.
Ciao Stipey75 ,
don't forget that the "vergin" Freescale pcs has the factory trim programmed......may be it was done in a different temperature and voltage environment you have in your application, BUT is surely a valid one.
So if you dont erase OR you read it before erase, you can "merge" the same S19 with the "local" trim value.....of course the "same-S19" have to avoid the trim addrees inside.
Have a good day
Franco
Thanks for the quick answer!
I solved in this way...tell me your opinion.
I edited s19, changed the trim value (0xFFBE) to 0xFF, now when the BDM load the application find the location erased and so saves the automatically generated value. I tried with three hw and it works? What do you think??
P.S.
Ciao Franco!!
Hello,
The programming algorithm is not being smart here. It is simply the FLASH characteristics that means you can't programme bits at 0 to 1. FF is probably being written over the top of the factory (existing) value but it is ineffective.
This should work for you as long as the trim is close enough for you.
Hi!
Thanks for the reply..
Just a few details more...
I create a s19 file with bootloader and app together in this way:
- use BDM pod to program Bootloader code itself
- use Bootlooader to load Application code via SCI
- connect BDM pod again and read all Flash content into a S19 file
- {if necessary remove the lines with empty Flash = containing FF bytes only}
With my final s19 complete (bootload+app) i have problems with SCI..i found it was trim value! Trim value is set at 0xFFBE by bdm when i flash the bootloader...then I program with sci the app and extract the complete file.
The problem is that this s19 complete file has a trim value set for that hw inside and when i use the load application option in hi wave bdm calculate trim value but doesn't write it because it's not blank! I made the trick...put 0xFF to the location 0xFFBE in s19 file and so it works because the TRIM value is blank during flashing app process...maybe now it's more clear!
Thanks
Hello Stipey75,
Which version of Codewarrior are you working with? From your previous posts, I assume that you are using CW6.x classic product.
One of the ways to trim your device is by utilizing automatic trimming functionality that is built into hiwave via P&E Expert Mode FLASH programmer along with USB ML 12 Multilink and Cyclone Pro hardware interfaces. Which hardware interface are you currently using to debug and program FLASH of your target devices?
Once you connect to device with hiwave debugger, please go to Expert Mode Programmer under MultilinkCyclonePro drop down menu. Please specify the .s19 file you want to program into your device and execute Erase, Blank Check, Program, Verify and Program Trim commands. The program trim command actually calculates and programs trim into designated NVM locations. P&E trim has accuracy of .2%.
Please note that program trim command is automatically executed if you are starting a debug session from within your Codewarrior IDE and choose to program FLASH. However, using Expert Mode programmer allows you to work with multiple devices, which seems to me like something you are interested in doing.
P&E also sells a stand alone FLASH programming software for S08 devices calls progHCS08 with a command line FLASH programming capability that supports scripting.
You can get more information about USB ML 12 and progHCS08 software using links below:
PROGHCS08:
USB ML 12:
Best Regards,
Zahar
P&E
Ciao Stipey75
even if the result is obviously the same and it works, instead of force the address FFBE to 0xFF, should be better to remove that address at all..... and better again, make it by the source code.
What I would like to underline you, is that the "Errors/mistakes" is always possible.
REMEMBER Murphy's low !!!
Don't forget that, If/when you erase the FFBE Flash sector, you will loose the factory trim value. Save it before erase, and restore it just after.
I underline this issue because if you don't, the first thing the SW normally do is copy the Flash value to ICGTRM register......you will continue to do it BUT now you will apply 0xFF that means at least 20% wrong speed....(was the effect of the first wrong programming algorithm.......reason why of this thread)
Franco