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.

IPCGR zeroizes DDR

Hello all,

I have modified project "Hello world" from
mcsdk_2_01_02_06\tools\boot_loader\examples\pcie\
to run this example on Core0 and Core1 in the L2SRAM
with the same codes for both cores.
To copy codes from Core0 to Core1 I used memcpy function.
All worked properly except one problem:
after operation
*(volatile uint32_t *)(IPCGR(1))=(1)
all valuable content of DDR (that was previously filled from Linux-host program)
was zeroized.

Please answer two question:
- why IPCGR zeroizes DDR;
- how to save the content of DDR during IPCGR.

I used:
Code Composer Studio 5.2.1.00018
mcsdk_2_01_02_06
MDSEVM6678L/MDXEVMPCI board

Best regards,
Stanislaw

  • Hi,

    All the interrupts are disabled except IPC interrupts and the host interrupts that are needed for the PCIe, SRIO (DirectIO), and HyperLink boot modes. During the boot process, the RBL executes an IDLE command on the secondary CorePacs and keeps the secondary CorePacs waiting for an interrupt. After the application code to be loaded in these secondary CorePacs are loaded and the
    BOOT_MAGIC_ADDRESS values in individual CorePacs are populated, the application code in the CorePac0 can trigger the IPC interrupt to wake up the secondary cores and branch up to the address specified in the BOOT_MAGIC_ADDRESS.

    Take a look at similar thread for wakeup other cores:
    e2e.ti.com/.../231854

    Thanks,
  • Hi,

    Thank you for your quick reply.

    I have no problem with the wake up.

    Core1 starts and properly works later.

    But the content in the DDR was zeroized after this operation: 
    *(volatile uint32_t *)(IPCGR(1))=(1)

    My questions was:

    - why this operation zeroizes DDR;
    - how to save the content of DDR during this operationI.

    Regards,

    Stanislaw

  • Hi,

    I read the post you suggested.

    I did not find validation for that assertion: "note that the ROM code reserves the
    last 0xD23F bytes of core "0" L2 RAM, please check sprugy5a.pdf (Bootloader user guide)
    paragraph 2.2 page #13"
    I use new version of the document SPRUGY5C and I did not find here information about this reserve.
    Could you plese explain it?

    I did not use only last 256 bytes in the L2SRAM.
    Function that I used to copy code from Core0 to Core1 is:
    memcpy((void*)(0x11830000), (void*)0x00830000, 0x4FF00);

    Defining of the L2 and DDR in *.cmd file:
    L2SRAM: origin=00830004h, length=04FF00h
    EXT_RAM: o=0x800c0700, l=0x8000000 // 128MB

    May be the text I used in the subject of my post is not felicitous.

    I'll try to explain my questions again.

    1) I did "write/read" test of DDR, then
    writing special codes to the array ddr_test[1000], located in the in DDR
    (i.e. "1" to ddr_test[0], "2" to ddr_test[1], "3" to ddr_test[2], etc)
    before line
    *(volatile uint32_t *)(0x02620244)=1; (that correspond to macros: DEVICE_REG32_W(IPCGR(1), 1);)

    2) After lines
    *(volatile uint32_t *)(0x02620244)=1;
    platform_delay(1000);
    I did "read" test of DDR, then "write/read" test of DDR.


    After the Core1 successfully wake up I have got next results (as the messages to UART):
    The "write/read"  test of DDR worked properly before line
    *(volatile uint32_t *)(0x02620244)=1;
    and after lines
    *(volatile uint32_t *)(0x02620244)=1;
    platform_delay(1000);
    it worked properly too.

    The "Read" test of DDR gave errors after lines
    *(volatile uint32_t *)(0x02620244)=1;
    platform_delay(1000);
    because of all content of the array ddr_test[0] was zeroized.
    Also was zeroized all other information that I wrote to DDR
    before line
    *(volatile uint32_t *)(0x02620244)=1;      

    But all another parts of the program worked properly in the both Cores.

    Unfortunately I can not send now complete program because of it too big
    and not clear for the disscussion.

    Regards,
    Stanislaw

  • Hi Stanislaw,

    I did not find validation for that assertion: "note that the ROM code reserves the last 0xD23F bytes of core "0" L2 RAM, please check sprugy5a.pdf (Bootloader user guide) paragraph 2.2 page #13" I use new version of the document SPRUGY5C and I did not find here information about this reserve. Could you plese explain it?

    Please refer device data manual section "2.4 Boot Sequence" for Bootloader section in L2 SRAM. Please find the device data manual from below link.

    From my understanding, IPC interrupt's are used to wake up the secondary cores. I would recommend you to debug the application using CCS by adding ddr_test in watch window.

    Thank you.

  • Hi Raja,

    Thank you for your reference.

    I ran this program in CCS (with the commented section which received data from Linux-host).

    But all worked properly in CCS.

    So it did not help to understand problem.

    Can you give a hint how it could take place?

    Regards,

    Stanislaw.

  • You mean to say "Issue persist with only PCIe boot"? Please confirm. Could you please share the whole project and steps to re-produce the issue?

    Thank you.
  • Hi Raja,

    The whole project is too big and not clear for the discussion.

    I think I should to close this thread and to begin new when I will ready to send clear short example.

    Thak you.

    Stanislaw

  • Hi,
    Yes, issue persist with only PCIe boot.
    Thank you.
    Regards,
    Stanislaw