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.

CCS/OMAP-L138: Can not emulate after booting from bin file generated using AISGen

Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAP-L137

Tool/software: Code Composer Studio

After programming the OMAP-L138 processor flash using a bin image generated using AISGen, I can not longer connect to either the ARM or DSP of my OMAP chip. Within the bin file, the ARM program simply brings the DSP out of reset. The DSP program was setup to initialize the part and spin.

I am using CCS 5.5 with a Blackhawk USB 560M to run emulation on my program designed hardware.

Within the target configuration, I am using a TI supplied gel file that is contained within c:\TI\ccsv5\ccs_base\emulations\boards\lcdkomapl138\gel\omap-l138_LCDK.gel.

When this gel executes on the ARM, I get the following error messages:

ARM9_0: GEL: Error while executing OnTargetConnect(): Page fault occurred reading 0x01E27800 at (*((unsigned int *) ((0x01E27000+0x800)+(4*LPSC_num)))&0x1F) [OMAP-L138_LCDK.gel:787] at PSC1_LPSC_enable(0, 0) [OMAP-L138_LCDK.gel:523]      at PSC_All_On() [OMAP-L138_LCDK.gel:244] at OnTargetConnect() .

ARM9_0: Trouble Reading Memory Block at 0xffff0000 on Page 0 of Length 0x5d: (Error -2030 @ 0x1000) Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error. (Emulation package 5.1.232.0)

ARM9_0: Trouble Reading Register REG_CP15_CONTROL: (Error -1060 @ 0x2E19) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.232.0)

ARM9_0: Trouble Reading Register REG_CP15_TT_BASE: (Error -1060 @ 0x2E18) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.232.0)

ARM9_0: Error: (Error -1060 @ 0x2E18) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.232.0)

ARM9_0: Unable to determine target status after 20 attempts

ARM9_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

When attempting to connect to the DSP, I get the following error message:

C674X_0: Error connecting to the target: (Error -1143 @ 0x0) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 5.1.232.0)

I am desperate need of being able to revive this board and program it with a different OMAP image. Unfortunately, this is the second board that we have gotten into a state where we can no longer connect the emulator to either the ARM or DSP. Any help in allowing me to revive these boards would be GREATLY appreciated!

Thanks in advance,

Kevin Elwood

  • Hi Kevin,

    I've notified the RTOS team.

    Have you tried booting your board from SD Card, i.e. with the linux MCSDK?

    Best Regards,
    Yordan
  • Kevin,

    It is really strange that you are running into this issue by just programming a image.  

    Can you change the boot switch to No boot mode and give this a try again. In No boot mode the ARM will not try to read the image flashed and will idle to allow users to connect over emulator. If you still see this issue, can you try to do a CPU and system reset from CCS Debug View using Run-> Reset=> CPU/SOC Reset.

    If you wish to reprogram the flash parts, then you can also run an NAND erase function to wipe the NAND clean using the Serial flashing tool and running the command.

    sfh_OMAP-L138.exe -erase -targetType C6748_LCDK -flashType NAND -p <COM_Port_Number> 



    please give this a try and let us know if any of these debugging steps help your hardware recover from this state.

    Regards,

    Rahul

    PS: Please specify if you have made any blue wiring or changes to the hardware. 

  • I am sorry, my OMAP-L138 is on a custom board that does not have an SD card interface or UART interface that an EVM might contain. To program the program image to the NOR flash, I run the emulator to execute a flash programming project that was developed in house.

  • You can try part of Rahul Prabhu suggestion. I have seen cases where code somehow manages to lock out the JTAG module. Don't know exactly why but it happens. You should tie the boot pins for emulation boot to stop your code from running. If you custom board does not have a jumpered boot to allow emulation vs NOR, you'll have to lift the boot pins and connect them as appropriate for emulation boot.
  • We are currently working on putting a jumper capability onto our board to switch between NOR and debug emulation. Will update when complete.

    Have you seen this phenomena on just the L138 or is this seen on other parts?
  • My experience is with the OMAP-L137 and the C6748. It has been several years since I worked with them. My memory is a bit fuzzy on which processor that I seen this happen.

    I believe emulation boot is just an single instruction that jumps to itself. Most code is usually a bigger loop. Some code seemed to connectable. Some not connectable. Never figured out why. It the boot pins fix doesn't work, you might have to look at the clocking. Your GEL script seems to fail just after PLL is started up?
  • Thanks for the help. We put a hardware switch on a failed board to allow boot from either NOR flash or emulation. When the switch is in the emulation mode, the target is connectable 100% of the time. I will have to change my boot mode to emulation on the other board to get it out of this "brick" mode, but at least it is fixable.

    Is this problem due to a bad bin file or a hardware issue associated with some weird timing setup via the bin file? I at least now have a system where I can verify my image file without having to worry about bricking yet another board.

    Again, thanks for you help!
  • I can only speculate. For a while I thought a tight loop might lock out the JTAG but the emulation boot is just a tight loop. MMU setting? Interrupts disabled for too long? Long DMA transfer? Hopefully someone has narrowed this down. It would be nice to know.

    I suppose a bad op code could brain the processor. I would expect an exception handler to catch that sort of thing - but the code executes fine which means it is not a bad op code.
  • Kevin,

    Can you try an experiment. When you boot from the AIS image, can you remove the GEL file from the target configuration and try to connect to the ARM so that the GEL file doesn`t run. If this works for you, there may be some conflict in the initialization performed by the ROM bootloader with the GEL file that may be causing this issue.

    Usually, GEL is used only when you are in emulation mode as the SOC clocks, DDR and PSC needs to be initialized for development, when you are using bootloader to start the application the ROM bootloader should perform the required initializations and not the GEL file. When you connect to SOC after the bootloader has run, you essentially try to override the configuration performed by the bootloader which may be the root cause of your issue.

    Regards,
    Rahul
  • Sounds plausible. Now that you mention it, connecting seemed better after I emptied out my GEL script into my startup code. Would explain some GEL script PLL clock problems.