HC9S08QE128 - Clock speed change without BDM

[Tbspd_TOK]

I'm using CW6.1 on MC9S08QE128. When downloading the code via P&E USBBDM the trim value is automatically adjusted, and the clock speed is correct (ca. 4MHz).

When running the unit without the BDM the clock speed is increased around 6%. This change is reflected in the baudrate(9600Bd) for the SCI, and the serial communication does not work anymore. When running the BDM the baudrate and clock is spot on, as described in the reference manual.

If I fix this by adding 1 to the baudrate counter value, the value is only 1.56% off and the unit work without BDM, but now it does not work in BDM mode. Around +/-4% is the limit if the unit in the other end is spot on the frequency.

Has anyone seen this before? If so, is there any way around this so the value programmed will work both with and without the BDM connected.

It looks like the trim calculation and frequency is offset by a BDM overhead? 

[pgo]

Dear Tbspd_TOK,

Just a quick check - Is your code copying the flash trim value(s) to the clock registers?

bye

[Tbspd_TOK · Accepted solution]

Thanks pgo,

I did not copy the trim values, due to the following paragraph in the reference manual rev2, Chapter 11.1 - ICS:

"The ICSTRM and FTRIM bits are normally reset to the factory trim values on any reset. However, any
reset that puts the device into BDM (a POR with the BKGD pin held low or a development tool setting
SBDFR[BDFR]) results in the ICSTRM and FTRIM bits being set to values of 0x80 and 0. When
debugging the MCU, the factory trim value can be used by copying the trim values from the Flash locations
shown in table 4-4."

When in BDM I checked the trim values and they were correct, so I supposed they also were that in normal mode, with reference to the manual.

I have just tested this and copying the trim values is the clue here, the manual is wrong in this. The program now works both in BDM and in release version with the same clock fequency. It looks like the manual is reversed in functional description, and completely wrong.

Thank you very much for the tip pgo.

[bigmac]

Hello,

Perhaps this rather serious Reference Manual error should be the subject of a Service Request, so that future revisions can be corrected.

Regards,

Mac

[pgo]

Dear BigMac,

I'm unsure if the manual is incorrect.  The one I referred to had the following (MC9S08QE128 Rev2, ch 4, p62):

The factory ICS trim value is stored in the flash information row (IFR1) and will be loaded into the
ICSTRM and ICSSC registers after any reset. The internal reference trim values stored in flash, TRIM and
FTRIM, can be programmed by third party programmers and must be copied into the corresponding ICS
registers by user code to override the factory trim.
NOTE
When the MCU is in active BDM, the trim value in the IFR will not be
loaded. Instead, the ICSTRM register will reset to 0x80 and the FTRIM bit
in the ICSSC register will be reset to 0

Footnote

1. IFR — Nonvolatile information memory that can be only accessed during production test. During production test, system
initialization, configuration and test information is stored in the IFR. This information cannot be read or modified in normal user or background debug modes.

This refers to two different non-volatile regions:

The Flash programmed by the "user" i.e. in the OP's case the flash programmed by the programmer.  This would need to be copied to the clock registers by the program code.

The IFR region which I believe is some kind of factory programmed region which contains a trim value done at the factory - I have not confirmed this but I believe it's what is implied by the above.  If this is the case I'm puzzled that the default clock value wasn't closer to the nominal value.  Perhaps the trim frquency being used was chosen differently to the factory trim value?

The above is different to most of the HCS08's I've looked at but appears to be an innovation on later devices.

The above is almost consistent with the portion posted by Tbspd_TOK, apart from the reference to the factory trim value in table 4-4 which refers to the usual flash locations (which may also still be programmed to factory trim values I suppose).

Perhaps not wrong but certainly ambiguous!

bye

[Tbspd_TOK]

Hello pgo,

I just downloaded this manual MC9S08QE128RM Rev. 2 - 6/2007. (File name MC9S08QE128RM.pdf) from Freescale.

The quote is still the same at page 203. The same info is also refered several places in the register description.

In my opinion this is clearly wrong and misleading, since it is defacto reversed from what really happens. I have also sent this info via my distributor to Freescale support.

Again thanks for your support.

TOK

[J2MEJediMaster]

Do what bigmac suggested. File an on-line service request on this matter by clicking here. On the service request page, choose Documentation for the Category and Error Report for the Topic. Be sure to explain in detail (like you did here) of what the error is.

---Tom