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.

Is ndk 2.24.02.31 version cache safe

Hi ,

I'm planning tho move all the NDk related buffers from l2 sram to ddr3 and configure l2 as fully cachable. I the ndk cache safe. Or there will be some issue with cache coherency. Whether I have to edit the source and compile ndk again to make the code work. If it is required , suggest the required changes. I'm using 6678 processor

  • The main person on the TI-RTOS that might know is out of the office this week. I've moved this to the device forum in case someone there might know in the meantime.

    Todd
  • Pratheek,

    Is DDR3 made cacheable in your app?

    The NDK stack code itself shouldn't need any cache invalidate or writebacks. These calls are typically done in the driver code for the NDK buffers (e.g. NDK PBM buffers).

    You can check the EMAC (NIMU) driver of the PDK for the 6678 for cache calls.

    Steve
  • Hi Steve,

    Ddr3 is fully cacheable.

    I had increased the packet buffers to 4096 rfrom 192 and has moved it to ddr3.

    Should I include any cache calls to the Nimu driver.

    My initial testing has showed, everything was fine but no improvement in throughput which I thought was easily possible.

  • Hi Pratheek,

    the number of allocated IP packets (NdkGlobal.pktNumFrameBufs) is not directly related to the throughput. You have to increase the RX and TX buffers used per socket instead, e.g. you can change the default setting for TCP sockets:

    Tcp.receiveBufSize = 64*1024;
    Tcp.transmitBufSize = 64*1024;

    The setting of NdkGlobal.pktNumFrameBufs defines only the size of the IP packet pool, which is mainly used by the EMAC/PA. The used number of packets is related and defined (hard coded) in the NIMU drivers of the processor specific PDK.

    Kind regards
    Sven