• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 1025 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.

L138 DDR2 Boot: Boot will happen only after intentional HW reset, but proper on L138 IRAM Boot

Shino Samuel
Intellectual 960 points
Other Parts Discussed in Thread: OMAPL138

Hi Friends,

I got an interesting problem & was unable to correlate different observations i found on debug. Requesting experts help.

#1 Intentional HW reset OR on system reset from Debug mode of CCS makes L138 DDR2 boot works perfect and not required on L138 IRAM Boot

First I thought Booting is not happening at all while using DDR2 for Boot sequence, but the init is going well and the PC is switched to entry point and executed further. From this state I tried to find the point where code halts by loading code symbol, and found debug pointer is moving in weird manner while single stepping (not in a sequential manner as i written in my code). But on L138 IRAM Boot all test above are giving desired outputs.

About this observation, I was not able find any conclusion and also unable to find relation of RESET & L138 DDR2 Boot which is not applicable on L138 IRAM Boot. I am using same board (custom board designed for a product) for all above mentioned test).  Some timing are there in this case? 

#2 [suspect] using Cache L1p/L1d & L2, but initializing cache in my code.  

_entry_point  >> PMIC Vge change to 1.3v for 456mHz operation support(i2c Init for PMIC interface) >> PSC wake up >> UART init >> Cache >> to scheduler loop

Here we are enabling cache on DDR,  while the same  .text section is residing in the DDR area where cache is enabling. Is this will create any problem? But we tried this code with JTAG and didn’t found any issues.  

[ if statement 3 is a problem, I don’t find links to connect with statement 2  ]

#3 [Related issue] when we moved entire code to DDR2, debugging using XDS510 is showing some problem but with XDS560 it is perfectly working

Debbugging code on DDR location using XDS510 shows pointer jumping weird on step in from CCS Debug, but with XDS560 it works perfectly. Again I was not able to relate code running on DDR and JTAG debug

 

All these issues  starts at my end after i added a compression library which created hole on .text and it not even fits to the full IRAM size. So i decided to move to DDR2. I have not using any CCS optimization in my code but relay on cache for equivalent performance as it is running on IRAM and i had appreciable result on debugging and testing. But these 4 issues arises after we tried to boot the entire code on platform.

Request suitable help from all.

Thank You, 

Regards

Shino Samuel, C-DAC (T)

 

 

  • 0
    TI__Mastermind 43660 points

    Hello Shino,

    Have you verified the DDR interface with simple test code like write and read into memory space ?

    The problem might be due to DDR timing issue. So i would suggest you to perform DDR interface verification.

    Regards,

    Senthil

  • 0
    TI__Guru** 116100 points
    What program are you using for testing this ?
    DSP or ARM ?
    Create one simple GPIO toggling example code & run it and test.
  • 0 in reply to Senthilkumar Srinivasan
    Intellectual 960 points
    Hi

    DDR2 is getting initialized properly,I tested by writing to DDR location from memory browser of CCS after connecting J-TAG. In Debug using J-TAG also DDR2 seems to be OK.

    Thanks
    Shino
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 960 points
    Hi

    Now i try this, by removing all firmware part and just boot a LED toggle and study the entire thing by bisecting point by point. In our product we given it as an update and observations are seen on site by our team. But the same update release is working perfectly on our prototype boards (exact same copy whatever on-site) and it passed all the test sequences.

    Most disturbing thing is that issue is only related when tried to boot from DDR2, but DDR is working perfectly i tested as i mentioned above by connecting J-TAG. The previous version firmware with IRAM boot and .bss section on DDR is working fine on the same.

    Now We just called back the platforms to study the issue with this update. I will post further help topics after i trying this, it will take at-least two days to get access to the hardware.

    Thanks
  • 0 in reply to Shino Samuel
    TI__Mastermind 43955 points

    Hi Shino Samuel,

    Shino says said:
    #1 Intentional HW reset OR on system reset from Debug mode of CCS makes L138 DDR2 boot works perfect and not required on L138 IRAM Boot

    yes, intentional HW reset is required in debug mode provided if you have the following points satisfied. But it is not the problem on OMAPL138.

    Do you get error something like this on the CCS?

    1. if you are running the souce code created for C6748 core to run on C6748 LCDK board  and running on OMAPL138 board, you are likely to get this error and do the reset. For example, the name of the source code itself indicates, "gpio_c674x_c6748_lcdkC6748" . Go to project properties and check the family and variant under CCS General.

    2.  Open *.ccxml, go and check which gel file is loaded? under "advanced--> C674x_0 and ARM9_0 --> bypassed???

    The reason for the required reset is OMAPL138 is a ARM bootable device, ARM core will wake up first which in turn will wake up the DSP core. If it is a code intended to run on DSP core and the DSP core is not yet wake up by that time, there is a possibility of this error.

     

    Regards,

    Shankari.

     

     

  • 0 in reply to Shino Samuel
    TI__Guru** 116100 points
    I thought you are using DSP app by you mentioning about L1/L2 cache,
    For OMAPL138 , do you have ARM bootloader to wakeup the DSP since OMAPL138 is ARM bootable and running the app on DSP core.

    Able to run any ARM app on OMAPL138 on DDR memory without any DDR2 issues ?

    Could you attach your test project here to reproduce from our end.
    Have you tried this on TI EVM & LCDK boards ?

    In case, you are debugging, then did you connect ARM core first and then DSP and load DSP app in CCS?
    Are you getting any error from emulator (XDS510USB) while connecting or loading or running or at any time ?


    All these issues starts at my end after i added a compression library which created hole on .text and it not even fits to the full IRAM size.


    That means, you are not facing any issues from DDR when you are not using compression library ?
    Else, IRAM boot is also working good when you are not using compression library and you've not tried IRAM boot with compression library since the whole project is not fit into IRAM size.

    Able to reproduce the problem on your custom board & TI EVM boards ?
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 960 points
    Hi all,

    Today I got the board , after some debug we spotted issue is related with DDR, but not initialisation error it is specifically related to the board. But the issue yet to be resolved with correct clues.

    What I observed in the board is after DDR init, in memory browser we can see the DDR memory is like someone had written some data , it's totally junk. But DDR is initialised correctly I can able to overwrite, write and read from memory window and also tested using code.

    But in one prototype I mentioned had DDR correctly initialised with zeros without intentionally setting to zero. This cause some problem in our code, board is booting properly but it crashes at one variable, If we initialised to zero and it is perfect with boot.

    But I was still searching for the reason how the junk data is present at power up specifically on this board. Testing is on progress

    Thanks for all comments. Request suggestion
  • 0 in reply to Shino Samuel
    TI__Mastermind 43955 points

    Hi Shino Samuel,

    Please check whether the un-initialized memory sections ( for example, .bss , .stack e.t.c., )  can be initialized to zero using the C6000 Compiler Optimization guide.

    For example, 

    SECTIONS
    {
    ...
    .bss: {} = 0x00;
    ...
    }
    Regards,
    Shankari

    ------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Intellectual 960 points
    Hi Shankari,

    We had done some init scheme to tackle this issue on platforms.

    But i want to discuss one observation i got while working on 8bit NAND boot with DDR2(no use of shared memory). In this case same scheme working on NAND 16 is not working on NAND 8 (all configurations are given correctly as per 8/16 bit device).

    some finding about this issue for suggessions & comments,

    # Initially it seems to be not booting, but boot is happened and stuck somewhere at code entrypoint itself ; all init from ais code is happened. if we connect J_TAG, we can observe the init configuration is successfully loaded to registers for NAND & DDR2.

    # the above problem will occur if we place IRQ/FIQ/SWI/...handlers on ARMRAM memory through linker file. But in NAND16 boot this is not an issue, and booting happens properly. So as a work around we initially loaded full code to DDR (all sections including .intvecs are allocated to DDR through linker file) and we found it is booting properly, after that the corresponding asm handlers are copied to ARMRAM memory just before the INT vector controller init for interrupt signal processing.

    Thanks & Regards