BRT Community
General Category => Discussion - EVE => Topic started by: darkjezter on August 27, 2019, 04:37:14 PM
-
Greetings all!
Related to my other post on aborting a pending swap operation, I'm also seeking to clear the co-processor's command fifo.
Based on the "Coprocessor Faults" section of the programming guide, and my assumption that writing to REG_CMD_READ during co-processor execution would likely lead to state issues, I first attempted a reset similar to the recovery steps listed in the guide. This however led to large portions of the screen not being displayed correctly. Assuming that I was trying to feed the FIFO too early in the co-processor's initialization following reset, I had inserted delays following the reset as a test, but saw no change in observed behavior.
What appears to work reliably is simply copying the contents of REG_CMD_WRITE to REG_CMD_READ. Upon doing this, I am seeing the INT_CMDEMPTY interrupt asserted, and correct 0xFFC reported by REG_CMDB_SPACE. I'm skeptical that this is the safest way to proceed, but have otherwise been unable to use REG_CPURESET for this purpose.
My chief concern with clearing the fifo with the x_WRITE to x_READ copy, is what happens if the co-processor is part way through processing a multi-word command. Would it still be expecting parameters to follow? This smells like a race condition waiting to happen.
Any feedback on this approach, or suggestions on what to do instead?
** Side note regarding REG_COPRO_PATCH_PTR: I'm seeing conflicting info on properly using this register during the reset. According to the register definition, this is a 16-bit read-only register, however the matrix orbital github code is using 32-bit operations on it. During my tests, I've tried both sizes, and even omitting the patch pointer write from the reset. All 3 of these cases gave me the same result.
Many thanks!
-
>** Side note regarding REG_COPRO_PATCH_PTR: I'm seeing conflicting info on properly using this register during the reset. >According to the register definition, this is a 16-bit read-only register, however the matrix orbital github code is using 32-bit >operations on it. During my tests, I've tried both sizes, and even omitting the patch pointer write from the reset. All 3 of >these cases gave me the same result.
All registers are 4-byte aligned, other bits than specified are reserved.
I am more curious about the registers that are not specified or specifically marked as reserved. :-)
Same for the undocumented commands. :-)
And a side note from me, the offset for REG_SPI_WIDTH is still wrong in the "BT81X Series Programming Guide" Version 1.1.
0x188 would be correct but it still says 0x180.