I found and cleaned up a couple of places where the various FSMs could be stepping on each other for memory access. With that repaired, I retested. The flaw uploading memory to the file was fixed. I also verified that when I pushed the buttons, I would "rewrite" the label+data or just data records.
Unfortunately, I didn't get the data bit values I expected from the updates. Further, the logic reported checksum validation issues, which totally makes sense. It left the header records alone and when I used the button to update only the data records, the label records were also untouched.
For example, the last word of the data record should be x5462, the output of the test generator, but I see xE440 instead. I need to watch the entrainment and sync process, then the deserialization, to found out whether I am picking out the bits properly.
The logic analyzer was wired, configured and the board set up for testing. Right away, I saw the deserializer tossing out words (that matched what was written into memory), but having no relationship to what I was emitting out of the test generator.
I made some tweaks to look at other signals and gave the logic a quick lookover. I can see that the deserializer is telling my UpdateRecord machine that it has accumulated a word after achieving sync. The word it presents is the same value xE440 that I see in memory.
This points me at the deserializer operation as the malfunctioning process. I did a dig through the logic analyzer traces to see whether I could spot the problem. It jumped out at me, particularly when I set up the scope to trigger on my update of the data record and display the WriteDataClock signal I was producing.
My test generator is not producing good output. Specifically, it is generating the sync bit followed by xE440 which is exactly what my deserializer picks up. The fault is in the test generator. Now I can focus on that logic and do some simulations to find the bug.
No comments:
Post a Comment