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

Unable to load code to ARM9 of OMAP-L138 on OMAP L138 EVM

Dinesh Balasubramaniam
Intellectual 480 points
Other Parts Discussed in Thread: OMAPL138

Looking for some help with some issues loading code on to the ARM9 processor in the OMAP L138.  I started off with a 'hello world' project using the ARM compiler built into CCS. The project builds correctly and I am able to connect to the target (ARM9 and C674x) but every time I try to load code to the ARM9 it fails with the following errors.

ARM9_0: Breakpoint Manager: Retrying with a AET breakpoint

ARM9_0: Trouble Setting Breakpoint with the Action "Process CIO" at 0x80005fd8: Error 0x00000008/-1066 Error during: Break Point,  Cannot set/verify breakpoint at 0x80005FD8 

ARM9_0: Breakpoint Manager: Retrying with a AET breakpoint

ARM9_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x80005e10: Error 0x00000008/-1066 Error during: Break Point,  Cannot set/verify breakpoint at 0x80005E10 

ARM9_0: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x80006374: Error 0x00000008/-1066 Error during: Break Point,  Cannot set/verify breakpoint at 0x80006374  

Couple of points to note:

- I am able to build the same 'hello world' project, load and run it to completion on the C674x core on the OMAP L138. (I'm assuming this means I can eliminate the emulator as a potential source of trouble).

- I have been able to boot linux on the ARM9 of the OMAP L138 using the SD card that ships with the OMAP L138 EVM. (I'm assuming this means the ARM processor is ok :) )

I found a couple of threads on the e2e forum that talk about these error messages but it isn’t clear if the issue being discussed is relevant to the issue I'm facing.

http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/98990.aspx

 

The thread below seems to suggest that problems with the GEL file can cause these issue. 

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/178360.aspx

GEL file used is attached to this thread. 

Looking through the startup_log file you'll notice a whole bunch of timeouts when enabling the various LPSC modules.  Seems like this might be the issue but I'm not sure how to fix this.  Any suggestions you have are welcome.

Thanks,

Dinesh

 

  • 0
    TI__Guru** 116750 points

    Thanks for taking the time to look through the forums before posting :) but we would need some more information before we can understand what is going on your EVM.

    What is your boot pins set to? Please set it to emulation boot mode and try again. This may not resolved the issue but I am just trying to eliminate external factors that could affect the process. Is the hello world project created from a template in CCS or have you written the example? Is there a linker command file associated with the project.

    Are you using the GEL file provided by Logic PD on your EVM?

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 480 points

    Hi Rahul,

    You pointed me to the correct solution.  The boot modes on the EVM was set to the default, which is configured to boot from SPI Flash.  After changing this to EMU Debug mode I am able to load and run code correctly.

    Here's the interesting thing though....when working with the C6748 SOM and with the C6748 on the OMAP L138 boot mode pins do not seem to have an effect.  With the setup, boot mode pins configured to boot from SPI1 flash, I was able to load and run code on the DSP.  What is different in the way the emulator works with the ARM and the DSP?

    The GEL files I used are the ones that ship with the CCS installation package located in C:\ti\ccsv5\ccs_base\emulation\boards\evmomapl138\gel

    Thanks for your help.

    Dinesh

  • 0 in reply to Dinesh Balasubramaniam
    TI__Intellectual 815 points

    Hi Rahul,

    I am the local FAE . I have the Zoom kit(experimenter kit) with OMAPL138 and my boot pins S7 are all set to OFF position and I dont encounter the problem Dinesh faced. Infact Dinesh and I went over the HW and SW setup to make sure we are not doing anything different.  I would like to understand why we are seeing different behaviours though the HW and SW setup appears to be the same.

  • 0 in reply to Harini Senthilvasan
    TI__Guru** 116750 points

    Hi Harini,

    Like I implied in my earlier response the boot mode pins should not affect the behavior while connecting to emulation pins of the board and connecting to the device.I  have 2 of these boards at my desk and both of them do not show this behavior. My recommendation came from observations made on other development platforms that I have worked with in the past. In the earlier cases they had turned out to be a board defects so I am inclined to say that there may be a board defect but I am not certain.  You might want to follow up with the Logic Pd if it is critical.

    The only other thing that I can think of is that there might be code flashed in the SPI Flash that boots and turns on the MMU on the ARM which messes up the connectivity and initialization. Easy way to eliminate this possibility is to erase the SPI flash and try the default boot switch settings again. Instructions to erase flash are given here:

    http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Serial_Flasher_Options

    Regards,

    Rahul