| ??? 02/22/09 23:34 Read: times |
#162657 - it's the same in v4 and v5, too Responding to: ???'s previous message |
... although in v4 the test for already set double-clock bit (FST.3) is missing... The bootloader code evolved, apparently.
The FST bits (double-clock and the three security bits - existence of two of them is denied by NXP, for some reason known only to them) setting procedures are shared between the ISP and IAP code. Obviously, they implemented only the ISP version of the double-clock setting, as they assumed there is no reason to do this from user code (btw. I too am curious to know, why do you want to do that in your application). And they documented it as a valid IAP function carelessly. The reason why it waits for scon.1=ti flag is, that within ISP, the intel-hex-like command is echoed back entirely, and the last character of it might be still being transmitted at the moment when the double-clock flag is programmed; and, after that, timer2 used there as baudrate generator is reloaded by a recalculated value. I see no problem implementing it as your own routine, but note what says the "original" SST89E564RD datasheet on FST bits IAP programming commands (page 42) - they programming instruction must be located in Block 1. Lorenzo Cappelletti said:
Do you think I should file a bug to NXP? Does anyone know how to do it? I have no idea how to file a bug to NXP, but, based on the state of the 'V' - line's documentation, I don't believe they do care. JW |
| Topic | Author | Date |
| Function "Program Double Clock" never returns in IAP mode | 01/01/70 00:00 | |
| You should check carefully | 01/01/70 00:00 | |
| I feel safe | 01/01/70 00:00 | |
| bootloader v6 is affected, too | 01/01/70 00:00 | |
| it's the same in v4 and v5, too | 01/01/70 00:00 | |
| TI=1 workaround | 01/01/70 00:00 | |
| 3-rd party programming and thebootloader | 01/01/70 00:00 | |
| bootloader self-upgraded to v7 | 01/01/70 00:00 | |
IAP ? | 01/01/70 00:00 |