I have a requirement to update a ARM7 processor while it is in ISP bootloader mode with/through a Cortex M3 processor. During the communications exchange between the updating devices I am seeing a periodic, random bit failure which either causes a resend to occur or causes an outright failure/termination of the sequence.
The bit failures are always an extra detected bit (ie: 0x20 is detected as 0x60, 0x2F is detected as 0x6F, etc). The Cortex UART RX buffer shows incoming data to be received reliably. The data is then sent up to the ARM7 device (in ISP mode). When the data is echoed back to the Cortex device is where the corruption occurs. As far as Ive seen, the corruption is not due to Cortex buffers wrapping around or being overwritten.
These failures seem to me to be a cause of a mismatch between the crystal frequencies of the Cortex and ARM7 devices, causing drift. The baud rates are a resonable 19200, which are supported by both devices either in ISP mode or not.
The next step is to scope the data but before I go to that length I thought I'd ask if anyone else has seen or come across this issue or one similar?
Thanks.
I think the scope will only confirm what you see - but the real question is what the cause actually is. Can you test your system when using the same device as the source and the sink of the data? Did you try slower data transmission rates? what protocol are you using (RS-232, RS-485, TTL etc.). Are you using the largest possible hardware FIFOs? what about environmental issues (noise...). I have seen in the past DC motors messing up sensor readings in a quite consistent way only because their engagement timing was fairly accurate.
Wire length, termination...?