• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 985 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3359: GPMC_WAIT stalls MPU

Manuel_Stuehn
Prodigy 20 points
Part Number: AM3359

Tool/software: Linux

Hi,

we have a FPGA connected to a Linux-driven AM3359 via (async)GPMC. Due to a bug in our FPGA bus implementation, a write access to a certain address in the FPGA would lead to asserting the gpmc_wait signal perpetually instead of the correct amount of time until the data is ready. This bug was discovered because after accessing this address, the whole CPU seemed to be frozen. No serial/network connection is possible, only a powercycle helps.

The question which bothers me now is, is it possible that a GPMC-wait stalls the whole CPU?

  • 0
    TI__Guru**** 393215 points
    The factory team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 86750 points
    Hi Manuel,
    you should be able to avoid a hang by enabling the timeout mechanism in the GPMC controller. See the description in the TRM about the TIMEOUT_CONTROL register. This will monitor a GPMC transaction and report an error after a programmable timeout period. The error would be logged in the GPMC_ERR_TYPE register and the offending address will be in the ERR_ADDRESS register. There isn't an interrupt associated with this error, so you would have to poll these registers to monitor the error.

    Regards,
    James
  • 0 in reply to JJD
    Prodigy 20 points

    Hi James,

    thanks for your reply. I'll have a look into the TRM about TIMEOUT_CONTROL. But nevertheless, is this the designed behavior that the GPMC-Wait does stall _all_ bus activity and can freeze the whole CPU? I'm very much hoping this is not the case! My concern is not the bug we fixed in the FPGA which caused the long wait but the mini stalls for each access of the FPGA which does correctly apply the wait until the data becomes ready. Are the GPMC and the CPU/RAM/whatever this tightly coupled?

  • 0 in reply to Manuel_Stuehn
    TI__Guru* 86750 points
    Manuel, unless there is another subsequent GPMC transaction, the internal operations of the device should not stall. I think the stall you saw was the accumulation of several GPMC transactions that couldn't complete, and thus the whole device operation would be affected. For example, if you perform several GPMC transactions which depend on each other (or which other CPU operations depend on), the processor will stall waiting for transactions to complete.

    Note that MMU configuration would have an effect on this as well. If you configure for bufferable writes, the GPMC writes can be buffered up and not require acknowledgement unless subsequent accesses are dependent on them.

    Regards,
    James