I don't think the IGetPut is onchip either after my wee check
thanks for the hint with AN2365. There seems to be a new version of the GetByte function which checks for inernal or external oscillator and uses the appropriate delay for the bittime. Here is the part from An2365
To provide a specific communication baud rate, GetByte calls the GetBit Subroutine. In the GetByte routine, two different clock sources, internal clock and external clock, are supported. For example, the MC68HC908LB8 usually has a trimmed internal bus clock of 4 MHz and an external bus clock of 2.4576 MHz. For the MCU to distinguish which clock source is currently selected, the ECGST (external
clock generator status) bit in the OSCSTAT (oscillator status register) is monitored in the GetBit
subroutine. When ECGST bit is set, the external clock is selected as a clock source. When the bit is
cleared, the internal clock is selected.
So this should work.
Posted: Wed Jun 29, 2005 9:29 am
Some people must have heard what you thought about 
Posted: Thu Sep 08, 2005 12:03 am
Anyone know where GetBit is located on the QB8? I've got the latest AN2365 and it's not listed in there. Yet GetByte does called GetBit, so I need to find where it is.
Posted: Mon Sep 12, 2005 1:11 pm
GetBit on QB8: Try entry @ 0x285D ...
It may move in next silicon, therefore I wouldn't use it in prod!
Cheers,
Posted: Mon Sep 12, 2005 3:38 pm
Thanks,! However, after further study I see that the in-ROM routine GETBYTE is calling GETBIT, so I really don't need to declare where GETBIT is located. That's all done for me, so to speak.
Thanks again.
Posted: Mon Sep 19, 2005 11:03 am
You're welcome,
Yep you're right about the GetByte calling GetBit, I did find surprising you wanted access to it 
Especially if it's not referenced, it could easily be moved between two compilation of the Resident ROM Code...
Cheers,
Posted: Mon Oct 10, 2005 11:06 am
Hi all,
AN2295 (Developpers' serial bootloader for HC(S)08 ) shows the ROM resident routines usage in the real functional application (Bootloading over serial line). If in doubt, check with the files there to see how the ROM is used - all bootloaders are tested.
For example, QB family has the ROM API located in RAM at $80 not at RAM beginning.
Next, CTRLBYTE must be completely cleared for page erase, not just one bit.
Basically, there are two main versions of the ROM routines:
1.) the one with fixed RAM API (just like in QT/QY/GR/GZ/EY/KX/JK/JL/LB/GT/QB/QC families), with some exceptions (LB8 entry points, GR/GZ speed settings and few others) it works generally like described in AN1831.
2.) better & flexible 'FILE_PTR type' (found in AP/JK8/JL8/LJ/LK) where a control block is defined anywhere in RAM and only pointer is passed into ROM routines. These are well described in respective datasheets and include also built-in EEPROM emulation.
Hope it helps.
Regards,
Freescale Czech
Posted: Fri Oct 21, 2005 4:58 pm
| Quote: |
CTRLBYTE must be completely cleared for page erase, not just one bit. |
Yes, I observed this too. The Metrowerks Flash API clears only the bit, not the whole byte. That's a bug.
| Quote: |
there are two main versions of the ROM routines: 1.) the one with fixed RAM API (just like in QT/QY/GR/GZ/EY/KX/JK/JL/LB/GT/QB/QC families), with some exceptions (LB8 entry points, GR/GZ speed settings and few others) it works generally like described in AN1831. |
Hmm, this makes me wonder. How different are the two ROM routines for RAM API? I was trying to use RDVRGNG, ERARNGE, and PRGRNGE and found that RDVRGNG was crashing my program. It never returned from subroutine. The other two work fine. I've since replaced the RDVRGNG with my own code.
I wonder if the location in ROM for RDVRGNG is different, or just radically structured differently?
Message Edited by RChapman on 01-24-2006 11:29 AM
