Forums » Software Development »
Dead board
Added by Thomas Catalino over 12 years ago
(posted on behalf of a customer)
- I tried to flash a new application to my module. Therefor I performed: sfh_OMAP-L138.exe –flash –v –p COM1 UPL_SPI_MEM.ais myApp.out.
- After a reset, the serial connection remained silent.
- I re-flashed with the u-boot image: sfh_OMAP-L138.exe –flash –v –p COM1 UPL_SPI_MEM.ais u-boot.bin
à Operation completed successfully.
- But the serial connection remains still silent.
I’m able to connect to the target with JTAG and run my application from the Shared Memory Section. But it is not possible to load the program into DDR
è ARM9_0: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0xfffd5684: Error 0x00000008/-1066 Error during: Break Point, Cannot set/verify breakpoint at 0xFFFD5684
ARM9_0: File Loader: Data verification failed at address 0xC1080000 Please verify target memory and memory map.
- ARM9_0: GEL: File: D:\Program Files\Texas Instruments\OMAPL138_StarterWare_1_10_01_01\build\armv5\cgt_ccs\omapl138\evmOMAPL138\uart\Debug\uartEcho.out: a data verification error occurred, file load failed.
Replies (3)
RE: Dead board - Added by Michael Williamson over 12 years ago
Well.
The Address 0xFFFD5684 is ARM local ROM code, so it's not surprising that you can't set a breakpoint at that location.
Is the UPL_SPI_MEM.ais your custom application, or the "UBL_SPI_MEM.ais" image provided by Critical Link for restoring a dead board?
If you are connecting to a module that has a questionable UBL and u-Boot code load (i.e., you've stomped it with your own software), then it's likely that the mDDR2 initialization code is not getting executed, and you will need to use the ARM gel provided. Normally, when you connect to the target the "OnTargetConnect()" function should be called in the gel file that will initialize the CPU, setup the memory map, and configure the core frequency to 300 MHz and the DDR to an operable 132 MHz (we actually now configure the mDDR to run at 150 MHz in UBL, but haven't migrated those settings back to the GEL file at this point).
After that, you should be able to open a memory window and inspect the 0xC0000000 region of DDR.
Hope this helps.
-Mike
RE: Dead board - Added by Stéphane Peter over 12 years ago
Hi Mike,
Thank you for your hints.
The good news first: Using the gel files (which is extended with the 150MHz for mDDR), resolves the mDDR problem such as I can load and run application over JTAG.
The bad thing is, that I've made no success in bringing the module into a normal operating mode.
The UBL_SPI_MEM.ais file (and the u-boot.bin file as well) is the one provided by Ciritical Link (MDK_2011-08-01).
Meanwhile, I also tried to reprogram the SPI-NOR Flash with the SPIWriter_ARM tool...
[ARM9_0] Starting OMAP-L138 SPIWriter. [ARM9_0] Will you be writing a UBL image? (Y or y) Y [ARM9_0] Enter the binary AIS UBL file name (enter 'none' to skip): D:\diverses\mitydsp_L138\MDK_2011-08-01\images\UBL_SPI_MEM.ais [ARM9_0] INFO: File read complete. [ARM9_0] Doing block erase.Enter the application file name (enter 'none' to skip): D:\diverses\mitydsp_L138\MDK_2011-08-01\images\u-boot.bin [ARM9_0] INFO: File read complete. [ARM9_0] Enter the app image load address (in hex): 1C080000 [ARM9_0] Enter the app image entry point address (in hex): 1C080000 [ARM9_0] Doing block erase.Doing block erase.Doing block erase.Doing block erase. SPI boot preparation was successful!
But unfortunately, also with this approach I haven't any output on the serial interface.
RE: Dead board - Added by Stéphane Peter over 12 years ago
All clear.
Today, I received a second Base Board - And with this new hardware, the CPU Board runs normally. --> So, a hardware defect on the Base Board is causing our problems.
Thanks for your time and help.
Best regards
Stéphane
