• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 440 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.

Using L2 RAM

Leon de Wit
Intellectual 470 points

Hi all

Most of my DM6437 application runs from DDR, with all internal memory configured as cache. I want to be able to switch to running a certain part of my application (a DDR test) solely from L2 RAM. To do this, I disable all cache and HWI:

BCACHE_Size cacheSizes = {BCACHE_L1_0K,BCACHE_L1_0K,BCACHE_L2_0K};

BCACHE_setSize(&cacheSizes);

HWI_disable();

before copying my code directly to 0x00800000. I then do a forced jump:

(*((Void(*)(Void))0x00800000))();

which starts the test.

The test is a simple writing of a counter to all DDR addresses, reading these values back and comparing with the expected values. This works well, until I hit a patch of DDR that has the value 0x10801080 in stead of the counter value expected. The location of this 'bad' patch of DDR is not consistant. Also, I can see the expected counter values further along in DDR. This creates the impression that something else is still writing to L2 RAM despite HWI and cache being disabled. Does anyone have any ideas as to what this might be?

Regards

Leon de Wit

  • 0
    TI__Mastermind 41665 points

    Leon de Wit said:
    This works well, until I hit a patch of DDR that has the value 0x10801080 in stead of the counter value expected. The location of this 'bad' patch of DDR is not consistant. Also, I can see the expected counter values further along in DDR. This creates the impression that something else is still writing to L2 RAM despite HWI and cache being disabled. Does anyone have any ideas as to what this might be?

    My money would be on the VPFE still being active, the video ports on the DM6437 have the ability to read/write into memory independently of the CPU (i.e. they are their own DMA masters) so it could still be going even through you have taken the precautions of disabling interrupts and cache. The big clue is the value you are seeing, 0x10801080 is the same value as video blanking data (it is black in YCbCr 4:2:2).

    As a quick test you could disable the VPFE by clearing the ENABLE bit in the PCR register to see if the data corruption goes away.

  • 0 in reply to Bernie Thompson TI
    Intellectual 470 points

    HI Bernie

    Thank you very much for the reply.

    I've disabled the VPFE, and I no longer see the 0x10801080 values as I did earlier. I still have random DDR positions with values other than what the test wrote there though, so I must have more peripherals active on the DDR somehow.

    Is there a way to turn off all DMA in one go, or do I need to do this device by device? Where could I read up on this? I've had a look at spru871:5 - IDMA. but if I understand your reply above correctly this is not what I'm looking for.

    Thanks again!

    Leon de Wit

     

  • 0 in reply to Leon de Wit
    TI__Mastermind 41665 points

    I am glad to hear the VPFE portion is at least fixed, though I am not sure what could be causing the problems in other random DDR positions. Aside from the VPSS and CPU configurable DMA (i.e. EDMA) there are only a few other internal bus masters, namely EMAC, VLYNQ, HPI, and PCI, since the latter three are more external master driven my next guess would be the EMAC.

    Leon de Wit said:
    Is there a way to turn off all DMA in one go, or do I need to do this device by device? Where could I read up on this? I've had a look at spru871:5 - IDMA. but if I understand your reply above correctly this is not what I'm looking for.

    This would be more a device by device configuration, I do not believe there is a global SCR (switched central resource) master disable capability, you would need to look in the user's guide for whatever peripheral you want to disable. The easiest way to do this would probably be to run the DDR test immediately after reset, as the SCR masters should all be in an inactive state at that point (that is the closest to a 'master disable' switch I know of). Note that the external master devices like HPI/PCI would still be active (i.e. if transitions are made on the pins it could result in memory writes) unless they are PINMUXed out even at reset (this is done to facilitate HPI/PCI boot modes).

    If you still see corruption running your test out of reset than you may have some other sort of memory instability, I assume you were seeing some instability leading to you wanting to run these tests?

  • 0 in reply to Bernie Thompson TI
    Intellectual 470 points

    Hi Bernie

    The VPFE portion is definitely sorted - I've not seen the blanking values again since following your advice. Thanks again!

    I'll go through the list of DMA master devices you listed one by one. I did not write all the code on this device, so it's possible something could be enabled I'm not aware of.

    Bernie Thompson said:
    If you still see corruption running your test out of reset than you may have some other sort of memory instability, I assume you were seeing some instability leading to you wanting to run these tests?

    The test is a step in our automated test setup for factory production. So it's more a case of a process and hardware check than a design verification.

    The value written unexpectedly is 0x00001010 consistently, so I'm guessing this is some device interfering in the memory rather than instability. I'll have to sift through the list you gave and see if I can catch it.

    Thanks again and all the best

    Leon de Wit

  • 0 in reply to Bernie Thompson TI
    Expert 2315 points

    Hi Bernie, sorry to latch in on this thread but my search on 0x10801080 brought me here.  This is a good value for black which is the opposite from my country where white is very distinct but it is diffucult to determine what is "black".  Anyway, I am writing white and black as edge data onto my UYVY colorspace data and know the black is 0x10801080 but am struggling to get consensus on what white is.  One source say it is 0xff80ff80, another say it is 0xeb80eb80 (for BT601 standard) and another one even tried 0xb480b480 but it is for 75% YCbCr (75% amplitude and 100% saturation).  Is my first source of 0xFF80FF80 the one I should use or is pure white a different value?

    Thanks, Jinh T

  • 0 in reply to Jinh
    TI__Mastermind 41665 points

    Jinh said:
    Is my first source of 0xFF80FF80 the one I should use or is pure white a different value?

    I believe this will depend on your system's color standard, if you are following BT.601 the max value would be 0xEB80EB80 as you suggest, using 0xFF80FF80 would be considered a violation since the 0xFF value is used in embedded sync codes. Depending on the device you are using and how you have your display configured, if you were to pass 0xFF80FF80 into the display port it may clip it to the BT.601 standard for you anyway. In any case, the brightest white would be with the luma at the highest value possible with the chroma value locked at the 0x80 mid point to avoid any color tint.

    If this is for a border of your output image I would try a few different values to see if you get any visible difference in the output image to see what looks best for your situation.

  • 0 in reply to Leon de Wit
    Prodigy 20 points

    Leon, did you ever sort out your remaining memory corruption issue?   We are trying to solve a similar issue (on a L138) and would welcome any insight you may have gained.

    -Brian

  • 0 in reply to Brian Carlson1
    Intellectual 470 points

    Hi Brian

    Following Bernie's advice above, we hunted down everything that has direct memory access. Originally I thought setting

    HWI_disable();

    would disable all of this, but because of the SOC architecture this isnt' the case. Other components have to be disabled individually. In our case we needed:

    VPFE_CCDC_PCR  = 0;
    EMAC_RXCONTROL = 0;
    EMAC_TXCONTROL = 0;

    since we're using the camera interface and Ethernet.

    Once these devices weren't accessing the memory anymore we had no further trouble with unexpected memory contents.

    Good luck!

    Leon