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.

RTOS/66AK2H12: TI/RTOS min_emacTcpExample and memory coherency

Part Number: 66AK2H12
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

We have an EVMK2HX board which runs the tcp example correctly.

We will, at some point, migrate to a board, the design of which is derived from the eval board.  We intend to use SYSBIOS. The SBC will only have DDR3B (0x6000_0000), not A.

As an experiment, we removed the DIMM from the eval board (so, nothing at 0x8000_0000), and generated a custom platform to locate the executable image at 0x6000_0000.

The code initializes but never completes initialization.  It hangs, in one case waiting in the function CSL_SerdesWaitForSignalDet.

We see in the data sheet memory map for the processor that 0x6000_0000 is non I/O coherent while 0x8000_0000 is I/O coherent.

Does this example run from non I/O coherent memory, or does it require I/O coherent memory?  If it requires the I/O coherent memory, is this true for all (or most) drivers under SYSBIOS? 

Thank you kindly,

Tim

  • Further info to add to Tim's : We are on the ARM and running the NIMU_emacExample_EVMK2H_armBiosExampleProject example from the PDK. Tim suggested disabling the cache as a test. With the cache disabled via cfg (Cache.enableCache = false;) I am able to ping the EVM.
  • Thanks, Mike. This confirms it is an I/O coherency issue; that the TI drivers require coherency (or alternately non-cached data memory). Data cache for DDR3 will be important for this application.

    Does anyone know if it is possible to make DDR3 at (0x6000_0000) I/O coherent, perhaps using the MMU for the ARM?
  • Hi,

    See the discussion e2e.ti.com/.../329614. You have to maintain cache coherency by software.

    Regards, Eric
  • Thanks, Eric. We suspected that was the case, and for software that we develop for this application, that is not a problem.

    However, we are running sys/bios on the ARM, and leveraging TI drivers and software, including ethernet drivers, SPI, I2C, MPI.

    Since these are TI drivers, do they have a build option that incorporates the necessary flush/invalidate operations that would allow us to run using DDR that is not I/O coherent?

    Regards,

    Tim
  • Hi,

    Sorry, the driver doesn't have build option to enable cache invalidate. As the HW doesn't maintain cache coherency, the SW has to do this. When using DSP code, we call CSL function like CACHE_invL1d(), CACHE_invL2() in the driver example. For A15, you need implement software at your side.

    Regards, Eric