BRT Community

General Category => Discussion - EVE => Topic started by: darkjezter on August 27, 2019, 04:37:14 PM

Title: Clear the co-processor command fifo
Post 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!

Title: Re: Clear the co-processor command fifo
Post by: Rudolph on August 28, 2019, 03:48:54 PM

>** 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.