• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1071 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.

Problem with setting "reset vector" of DSP using ROM ID: d800k002 of OMAPL138

ROGERG
Mastermind 36170 points
Other Parts Discussed in Thread: OMAPL138

Hello,

I hope somebody can give me some hints for my problem in order to solve it.

***Hardware***:      

2 Hawkboards (one with ROM ID d800k002 and the other one with ROM ID d800k004)

***Software***:

1. ARM application => wakes up the DSP, sets the reset vector of DSP to appropriate _c_int00 address of DSP application (HOST1CFG register)   [Code for shared RAM]

2. DSP application => blinking LEDs [Code for DDR2]

I am generating the binary file by combining the two out files of the applications with the AISgen tool.  Flash the binary with NAND writer to NAND flash. So far so good.

When I am doing this on the hawkboard with d800k004 ROM ID everything works fine and the program runs after reset as expected.

When I am doing this on the hawkboard with d800k002 ROM ID it is not working at all (no blinking LEDs). I have changed the appropriate setting for ROM ID in AISgen tool of course before generating the binary file. I have checked the reset vector value in HOST1CFG register and it was not the one which should have been written by ARM application. I analyzed the final binary file and saw that in compare to the other binary file for ...004 ROM ID there was an additonal data section added at start address of shared RAM (I do not know why?). Changing the location of ARM application to IRAM of ARM did not solve the problem. The reset vector was still not set. Doing the same change to hawkboard with ...004 ROM ID worked fine again.

So my assumption is that the problem has something to do with the ROM ID revision of OMAPL138. Does anybody have an idea what is going wrong here or which difference between the two revisions might be responsible for the problem.

I would be very thankful for every hint anybody could give me. Thanks!

  • 0
    TI__Expert 8785 points

    What is your bootmode, NAND16 or NAND8?  Based on the bootloader appnote, http://www.ti.com/lit/pdf/sprab41, d800k002 does not support NAND16 boot.

    --Christina

  • 0
    TI__Guru* 83925 points

    Hi

    Discussing this with the ROM team, one difference between the 2 ROM versions came up, that could be impacting your setup

    D800K002 ROM (Rev 1.0 devices), the Kick Registers (SYSCFG modules) are written to, to lock out SYSCFG MMR access upon ROM completion

    D800K004 ROM (Rev 1.1 devices), the Kick Registers (SYSCFG modules) are written to once to unlock and then not touched again i.e on ROM completion the SYSCFG MMR access is not locked

    Additionally

    D800K006 (Rev 2.0 devices), we have disabled the KICK registers altogether , and they will not lock/unlock the SYSCFG MMRs.

    Could it be that for Rev 1.0 based Hawkboard , the accesss to HOST1CFG are not landing properly , since the ROM locks the registers by writes to kick registers?

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    TI__Mastermind 36170 points

    Hi,

    thanks for the replies. I am using NAND 8-bit in both cases.

    The lock out of the SYSCFG MMR access might be the reason for this behaviour. As I wrote in the first post, the ARM application sets the HOST1CFG after setting the Kick Registers with appropriate values to unlock and get access to SYSCFG MMRs. Does that mean that for Rev 1.0 I am not able to unlock the SYSCFG registers within the ARM application? How else can I set the reset vector of DSP for Rev1.0?

    Thanks and best regards

    Gregor

  • 0 in reply to ROGERG
    TI__Guru* 83925 points

    GINNI said:
    Does that mean that for Rev 1.0 I am not able to unlock the SYSCFG registers within the ARM application? How else can I set the reset vector of DSP for Rev1.0?

    Are you also making sure that that your ARM side application has ARM in supervisor mode (priv mode) to access the kick registers to unlock (in case of Rev 1.0)? In your rev1.1 devices this would not matter, as the access to HOST1CFG should be possible as the kicker registers were not written to in the end of the rom code to lock it back.

     

    The access to SYSCFG registers was left unlocked in Rev 1.1 ROM and neutralized in Rev 2.0 device to avoid issues like the ones mentioned in the following post

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/29241/101549.aspx#101549

  • 0 in reply to Mukul Bhatnagar
    TI__Mastermind 36170 points

    Hi Mukul Bhatnagar,

    thank you for the further hint. You are right I did not check this. At the moment I do not have the hawkboard with Rev.1.0 for further testing. As I understood I can put the ARM into system or supervisor mode only if I am already in a privileged mode. Would it be correct if I would do the following.

    1. Setting up an RTSC project for ARM, where I start BIOS -> Task -> Swi_post()

    2. In the Software Interrupt Service Routine (Processor should be now in IRQ privileged mode) I can set the KICK0/1 and HOST1CFG registers with appropriate values I need.

    Is that a possible way or is there probably an easier way to do it? I am going to test it next week, when I get back the hawkboard with Rev. 1.0.

    (I use SYS/BIOS 6.30.02.42 with CCSv4)

    I appreciate your help. Best regards.

     

  • 0 in reply to ROGERG
    TI__Guru* 83925 points

    If ARM9 is in user mode, then to get to supervisor mode, you would need to execute a SWI. Hopefully that should resolve it. If you run into issues doing this on ARM BIOS6, you can always seek more advise on this on the BIOS forums.

    Regards

    Mukul