I was so easily deceived. All those byes flying around and not being decoded reliably. I spent a long time on the receiver and in frustration checked the transmitter data stream.
You could have heard a pin drop.
When it was transmitting two good start pulses the data was being ruined by timing errors:
The shaded areas above show where the delay in changing state was recorded. There were also examples of start pulses being mistimed.
There was no reason for the missing clock cycles. Op codes which were supposed to take 1 cycle were sometimes times taking longer. No interrupts were firing. After days of testing Thomas, author of STM eForth, and I think this is caused by the pipe-lining of execution instructions. The programming manuals makes an off hand reference to this by pointing out "In some cases, depending on the instruction sequence, the cycle taken could be more than that number." Add to that the fact that the pipeline fills differently for RAM compared to Flash.
Which could explain why, when sending a string of high/low instructions which should have produced a nice 50:50 duty cycle waveform I got the following when executing from RAM
And this when executing from flash.
Same code. I didn't zoom in as close on the flash version but you should see that when the code was executed in RAM every second pulse lost a time unit during the low period, but when executed from flash the lost time unit occurred during every second high period.
This was eventually traced to the way the pipeline fetches code. Fixed by changing the code so that the pipeline was always reloading. Consistent outcome but slower. Required an 8fold increase in the CPU clock to 125kHz to compensate for this.
No comments:
Post a Comment