We are using the BF527 which we boot using TWI host mode (mode 0110). The .ldr file is read from a TWI eeprom and written to the BF527 in 64 byte chunks using a uC. The loader has been implemented quite simple until now, by sending 64 byte chunks until the BF assert nack on a byte (this makes the number of bytes sendt = .ldr file nbytes + 1). The hwait signal is not used, and it relies on slave clock stretching on the TWI. This works quite fine, but once the BF boots, its twi module might indicate a slave byte received due to the extra byte sendt.
To get rid of this side effect and not having to handle this in the BF code, we have rewritten the loader to send the exact amount of bytes in the .ldr file. At first this seemed fine, but this does not always work. In the cases it does not work, we have to send an extra byte before the BF then boots. Debugging of the boot loader rom code shows that the BF is actually waiting for one more byte before the final block is concluded complete and the BF boots correctly. It is hard to conclude with what this problem actually is, but we have solved it by interpreting the .ldr file and send the data on a block by block basis, which then will case a sligth delay after end of each block.
Has similar behaviour been seen by anyone else?
Is there any known bugs in the boot rom code for TWI host boot that can cause this behaviour?
It seems like the data is received correctly, but it is not counted correctly somehow, maybe due to TWI fifo handling?
Scoping shows that the hwait signal occasionally is active up to two twi bytes, and then clock stretching is started.
Any answers is appreciated,