??? 02/20/07 14:39 Read: times |
#133321 - The reason I asked is... Responding to: ???'s previous message |
We have a customer that needs a continuing supply of 89C668s. They need the RAM and don't want to rewrite their code. My task in all of this is to create the ISP and IAP code for the internal ROM. (And no, this is not a homework problem)
Matching the documented calls was easy. However, half of the IAP functions are undocumented, as well as 1 of the ISP functions. To get a better understanding of the true requirements, I have been studying a number of applications that use IAP and ISP. And that includes Erik's "No-Touch". I now understand Erik's method as contrasted to solution. I think it would be better to call the IAP with 86h (feed watchdog) than with 06h (don't feed watchdog). Calling the IAP routine with R1 = 6 programs the status byte with the accumulator contents. This is a complicated procedure and takes many instructions to accomplish. The software also repeats the programming 32 times, just to make sure it "stuck". I have not added up the numbers, but it could easily take well over 1ms to accomplish. The watchdog has a timeout of 16K machine cycles (x6 or x12 clocks). The IAP routine consumes enough time so that the timing of the last watchdog reset becomes critical in this application. The IAP software seems to go through a sequence of "turn-on" the flash, put it into a "mode" (data, status byte, security bits, etc), perform the operation (read, write, erase), and then "turn-off" the flash. I do not know how NXP has internally connected their reset with their flash logic, but I think that it would not be a good thing to have the watchdog reset the part in the middle of a flash write operation. |