DM6437 problem running BIOS from DDR

I've never had this issue.  When you halt what shows up in the disassembly window?  Can you scroll up a bit to look for a symbol to figure out what function is executing?  You might also just open a memory window and point it to DDR2.  Make sure it has maintained all the code/data and not just gone to zero.

I've done BIOS projects with everything located in DDR2 so I'm not sure if you have a board issue or what...  A really simple test is to just open a memory window to DDR2, make it really big, and then refresh it a bunch of times.  If you see a lot of red indicating that data is changing then the DDR2 is not setup correctly.  Try poking a few values in there and make sure they stay.

I have ran a complete memory test over all of DDR2 memory while running from IRAM. I have duplicated this problem on

two different DM6437 boards. Were you able to duplicate my problem using the steps above?

I'm sorry but I don't have a board available at the moment.  However, I can tell you with certainty that I have run with everything placed in DDR2 in the past.  Do you know if anything is burned into the flash on your boards?  Please let me know what you see in the disassembly window.  The failure mechanism should provide a big hint as to the real issue.

It is hanging at the same spot each time. No symbols available.

0x80006BF0:   1001E002            SWBP          0
0x80006BF4:   00000000            NOP
0x80006BF8:   00000000            NOP
0x80006BFC:   00000000            NOP

            etext, __etext, .bss, __bss, bss, HWI_dispatchTab:
0x80006C00:   00000001            NOP
0x80006C04:   10800DE4 ||         .word         0x10800de4
0x80006C08:   800065E8     [ A1]  MVKH.S1       0xcb0000,A0
0x80006C0C:   00000000            NOP
0x80006C10:   1001E002            SWBP          0
0x80006C14:   00000000            NOP
0x80006C18:   00000000            NOP

Looking at the map file this seems to be in main.

80006ba0   __register_lock
80006bc0   __register_unlock
80006be0   _main
80006c00   $bss
80006c00   .bss
80006c00   _HWI_dispatchTab

If I try to single step from the halt point (0x80006BF0) I core dump and eclipse crashes.

The above issue was compiled with 7.0.2 code generation tools. I get different

results with 7.0.4 code generation tools:

Trouble Halting Target CPU:
Error 0x00000020/-1202
Error during: Execution,

CPU pipeline is stalled and the CPU is 'not ready'. This means
that the CPU has performed an access which has not
completed, and the CPU is waiting. The target may need to be
reset. The user can choose 'Yes' to force the CPU to be 'ready'.
When this is done, the user will have the ability to examine
the target memory and registers to determine the cause of the
CPU stall. If CPU hang is caused by application and it has been
forced to be 'ready', the CPU should not be run without a reset.

  Yes        - force CPU ready (might corrupt the code)
  Disconnect    - disconnect CCS so that it can be reset
  Retry        - attempt the command again

Thanks,

Thomas Daigneault said:

It is hanging at the same spot each time. No symbols available.

You don't see a symbol for main above it at 0x80006be0?  What compiler options are you using?  Make sure symbolic debug (-g) is turned on.  Also make sure optimization is off.

Thomas Daigneault said:

0x80006BF0:   1001E002            SWBP          0
0x80006BF4:   00000000            NOP
0x80006BF8:   00000000            NOP
0x80006BFC:   00000000            NOP

            etext, __etext, .bss, __bss, bss, HWI_dispatchTab:
0x80006C00:   00000001            NOP
0x80006C04:   10800DE4 ||         .word         0x10800de4
0x80006C08:   800065E8     [ A1]  MVKH.S1       0xcb0000,A0
0x80006C0C:   00000000            NOP
0x80006C10:   1001E002            SWBP          0
0x80006C14:   00000000            NOP
0x80006C18:   00000000            NOP

This looks corrupt.  For example, expect a pair of instructions MVKH/MVKL in the interrupt vector (HWI_dispatchTab) but one of them shows up as ".word" meaning that it is not correctly disassembling as a legitimate instruction.

A couple further questions:

1. Can you copy/paste the entire "main" from the disassembly window?
2. Can you relocate your code back to internal memory and get the corresponding captures?

 Compiler options:

Full symbolic debug (--symdebug: dewarf, -g)

No optimization

Main in DDR assembly dump:

main:
0x80006BE0:   008CA362            BNOP.S2       B3,5
0x80006BE4:   DEC5BEB3     [!A0]  SHRMB.S2X     B13,A17,B29
0x80006BE8:   4D9258F6 ||  [ B1]  STW.D2T2      B27,*--B4[B18]
0x80006BEC:   DA6037BF     [!A0]  STB.D2T2      B20,*+B15[24631]
0x80006BF0:   1001E002 ||         SWBP          0
0x80006BF4:   00000000            NOP
0x80006BF8:   00000000            NOP
0x80006BFC:   00000000            NOP

Main in IRAM assembly dump:

            main:
0x10807460:   008CA362            BNOP.S2       B3,5
0x10807464:   00000000            NOP
0x10807468:   00000000            NOP
0x1080746C:   00000000            NOP
0x10807470:   00000000            NOP
0x10807474:   00000000            NOP
0x10807478:   00000000            NOP
0x1080747C:   00000000            NOP

            etext, __etext, .bss, __bss, bss, HWI_dispatchTab:
0x10807480:   3BEB9EBE     [!B0]  STB.D2T2      B23,*+B15[27550]
0x10807484:   26C9513B            .word         0x26c9513b
0x10807488:   08284198 ||         .word         0x08284198
0x1080748C:   E80F3D78            .word         0xe80f3d78
0x10807490:   B1DC1B9F ||  [!A2]  LDBU.D2T2     *+B15[23579],B3
0x10807494:   8345D030 ||  [ A1]  MPY2.M1X      A14,B17,A7:A6
0x10807498:   81E5B801     [ A1]  MPY32.M1X     A13,B25,A3
0x1080749C:   F57942FF ||         .word         0xf57942ff
0x108074A0:   CA2FEF57 ||         .word         0xca2fef57
0x108074A4:   74FB3425 ||  [!B2]  LDB.D1T1      *A30--[25],A9

Thomas Daigneault said:

3. Under new tab - Create a NewTargetConfiguration.ccxml

       Set to: Texas Instruments XDS100v2 USB Emulator

              TMS320TCI6482

              Under Advanced Tab: Set init script to evmdm6437.gel

Thomas,

You chose the TMS320TCI6482 for your device for some reason, or was this a typo in the instructions you posted? The TCI6482 has a functionally equivalent DSP core but not precisely equivalent. Please try creating a new target configuration using the TMS320DM6437 as the target device and see if this helps at all.

Regards,
RandyP

The Blackhawk XDS100V2 Rev D does not support the TMS320DM6437 directly. I found a post on the forum that said to use the TMS320TCI6482 which

supported the C64x+ core. Seems to me that the problem here is either the BIOS, a CCS compiler/inker setting, or a DM6437 board setup. The DDR2 is good. The

problem is the same on two different boards. I have tried downloading a LAB from the TI BIOS class and compiling it. I have the same problem. It's like

the load is being corrupted as the emulator is loading it into RAM?

Is this the EVM or your own hardware?  If it's the EVM have you tried the onboard emulation?

A couple things to try:

(1)  Run 'dis6x' (in cgtools/bin) to disassemble the .out file.  Redirect the output to a .txt file.  After loading with CCS, review the loaded code in a disassembly window to see if it matches the dis6x output.

(2)  if you have access to a TI EVM board, then build/load/run the BIOS 'hello' example.  If your memory map matches the TI EVM, you might also be able to run this on your board.

(3)  I wonder if your DSP speed is incorrect?  I think load of code might be OK, but if you are overclocking the DSP, then the execution would be unpredictable.

Please point us to the thread that said to set your Target Configuration to reference the "Texas Instruments XDS100v2 USB Emulator" but to use the TCI6482 instead of the DM6437 listed there. .

Have you tried the DM6437 configuration and it failed?

In my installation of 4.1.3, there is no BH XDS100v2 listed, so all XDS100v2 emulators would use the TI drivers, and I would therefore expect them to all support the same products.

The hardware I am using is the evmDM6437. We do not have real hardware yet. I have tried the onboard

emulator and have the same problem. I have tired BIOS labs, projects from the dvsdk for dm6437, and a stubed

out main.c new project. Same issue. Works in IRAM, crashes when ran in DDR2. The XDS100 emulator works

when everything is ran from IRAM.

Randy,

This was the thread that I found when trying to get the XDS100V2 to work with my DM6437. I updated the

blackhawk driver and update the tools looking for the EVMDM6437 target. There is no support from for the EVMDM6437

under the target configuration tool. So I followed this thread and the emulator worked running from IRAM (not DDR2).

Using XDS100 with DM6435

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6571/24956.aspx#24956

Thanks Fly,

    I able to emulate DM6437 with XDS100.My actual requirement is to connect multicore DSP(TCI648x series) with XDS100 emulation.

Still I could not able to connect  multicore DSP(TCI648x series) with XDS100 emulation.Can you suggest me anything for same ?

Brad,

To be clear, and please correct me if I am wrong, the EVMDM6437 selection is to use the on-board emulation, right? Or is the on-board emulation an XDS100v2 so it is identical to using the BlackHawk emulator?

Randy

RandyP said:

To be clear, and please correct me if I am wrong, the EVMDM6437 selection is to use the on-board emulation, right? Or is the on-board emulation an XDS100v2 so it is identical to using the BlackHawk emulator?

Not quite.  Let me explain!

The intent is for the emulator to be independent of the board. 

• Emulator
  • If you're using on-board emulation then you choose "Spectrum Digital DSK-EVM-eZdsp onboard USB emulator".
  • If you're using the external XDS100v2 you choose "Texas Instruments XDS100v2 USB Emulator".
• Processor/Board
  • DM6437 no gel file  -- select "TMS320DM6437"
  • DM6437 with EVM gel file -- select "EVMDM6437"

If it's your own custom hardware for DM6437 then I would recommend that you copy/paste the gel file from the EVM and make adjustments to customize for your own board, e.g. PLL and DDR settings.  Then you can select "TMS320DM6437" go to the Advanced tab, click on the 64x+ core, and then add your new gel file as the one for it to use.

FYI, there are a couple sections related to Target Configuration files here:

http://processors.wiki.ti.com/index.php/CCSv4_Getting_Started_Guide

Brad,

I have the Target Configuration Tool set to XDS100v2 and there is no selection for EVMDM6437. I am using CCS Version 4.1.3.00038. What version are you

looking at?

Regards,

Thomas

Thomas,

I am also running CCSv4.1.3.00038. In my Target Configurations->Basic tab->General Setup area, in the Connection drop-box I have both "Spectrum Digital DSK-EVM-eZdsp onboard USB Emulator" and "Texas Instruments XDS100v2 USB Emulator". Selecting either of those two, I find both EVMDM6437 and TMS320DM6437.

I do not recall installing anything special that would have added these, but anything I would have installed would also be available to you. If your installation was limited in any way, i.e. not a full-feature installation, I recommend going back and re-installing CCSv4.1.3.00038. I was told you can re-install on top of the existing one to add features.

If there is any support on the CD/DVD that came with the EVMDM6437, check if there are emulation drivers there.

Do you have the full path to the GEL file: <CCS install dir>\ccsv4\emulation\boards\evmdm6437\gel\evmdm6437.gel ?

Randy

No, This is not a 'Verified Answer'.

I am testing on a EVM6437 Board with the same Bios that Thomas is using on Code Composer v3.3 (v3.3.82.13 and Bios v5.41.07.24) and I am having the same exact problem Thomas is. 

The Bios will not start/boot up in the EVM6437 Board's DDR Memory.  I have tracked it down to the GBL_init function in the Bios_init routine.  Somewhere in this GBL_init routine, I see that the Bios is either locked into a memcpy() function loop, or the DM6437's Program Counter is stuck at some random address that is in the reserved page 0.

I get this very same problem when I use the BIOS dsk.C6424 platform configuration as well as the dsk.evmdm6437 platform configuration.  I have also downgraded to the v5.33.06 Bios and still see this exact symptom.

The BIOS startup does work if the Bios is located in the L2_IRAM on the EVMDM6437, however, using both of my BIOS versions.  Unfortunately, this is not a good solution for us as it means we cannot use the L2 Caching capability of the DM6437 (We do not want have executable code and Cache split in L2 due to the C64x+ Cache Blocking bug).

Could someone please enlighten us as to what exactly GBL_init in the BIOS_init routines is doing, so that maybe we can get an idea as to exactly what the DM6437 does not like about the code?

Thanks,

Is it possible to zip up a test case that includes your exact configuration.    Are you using the TI-EVM or custom hardware?   If you send test case, we'll try to reproduce on our EVM.

GBL_init() fills stacks and LOG buffers with init values.    It also initializes the caches.   One thing to try would be to set your L2 size to '0' to rule out a cache conflict.  Remember that L2 can be configured for memory or cache.  If have references to L2 when it is configured for cache, bad things will happen.

James and Thomas,

After some time elapses, we will sometimes mark a thread Answered if it looks like the posts could have answered your question. But we appreciate that is not always true, so thanks for coming back and pointing this out. The Answered flag is removed.

Minor points, first:

JRasmussen said:

We do not want have executable code and Cache split in L2 due to the C64x+ Cache Blocking bug

The easy way to avoid the SDMA/IDMA stall Advisory 1.3.11 is to allocate all L2 as cache. This is not the only way, though. There can be a lot of value in performance from having some of L2 used as RAM. But you do have to be aware of the Advisory 1.3.11 issues and protect from those. For example, putting program code in L2 RAM would not lead to the stalls because no external master would access this space. Another example is to have data variables like the stack in L2 RAM since those will not be accessed directly by external masters through the SDMA port.

All that said, BIOS is probably not the most critical part of your application, so it would not be a big advantage for it to be in L2 RAM anyway.

RandyP said:

Do you have the full path to the GEL file: <CCS install dir>\ccsv4\emulation\boards\evmdm6437\gel\evmdm6437.gel ?

You never responded back to my last question from my Oct 16 post. Were you able to reinstall and find the EVMDM6437 and TMS320DM6437 selections for the emulator selections?

I have attached a copy of this GEL file. It is essential for initializing DDR2 so that you can operate the board correctly. The right emulator selection is also essential for proper operation.

The fact that BIOS works from L2 and not from DDR2, and the fact that you have garbage showing in your DDR2 listings, this all says that DDR2 is not configured well. This does not point to a problem in the BIOS code, but in the system initialization that needs to happen before loading the program. This should be done by CCS through the GEL file when using JTAG to load the program, and it should be done by the bootloader when loading from some other means. BIOS does not initialize the DDR2 peripheral interface.

Please let us know what results you get using the GEL file, and also whether you have been able to find the DM6437 selections for your Target Configuration.

Hi Karl,

I will send you my entire TI project later today or at least by Monday.  How exactly do you want me to send you the entire zipped contents?

In answer to your questions:

I am using the TI-EVM board for the 6437 (TMS320DM6437 EVM).

I have set L2 size to '0' which is turning off the cache, and I have set the BIOS .tcf file to not allocate anything to the L2 Ram.

As far as cache control, I am letting DSP Bios via the .tcf file take care of that.  The EVMDM6437.gel file (which I will also include in my .zip file) has Cache setup options, however, this is the file that I got from Code Composer 3.  I have not modified this file from the original installation.

Thanks,

The forum has an option to attach file.  Make a .zip file and use the "paper clip" icon on tool bar to attach your .zip.

Please include your .gel and prebuilt .out file in case we have problems rebuilding your project.

Thanks,
-Karl-

In the mean time you may also want to try using the gel file that Randy posted.  The version Randy posted, which is the latest, specifically mentions changes to the DDR configuration.  Is there a revision letter on your board?  It looks like the final revision was E.

Hi Karl,

Here is the attached .zip of my troublesome project running everything into DDR2 memory.  The .gel file used is in the IWB/GEL folder, and the *.out file is under the IWB/Debug directory.

Let me know what you find please and Thanks for looking at this.

7024.IWB.zip

Brad,

Our TMS320DM6437 EVM boards show Rev. G.

Thanks,

Hi Randy,

To answer your questions:

RandyP said:

James and Thomas,

The easy way to avoid the SDMA/IDMA stall Advisory 1.3.11 is to allocate all L2 as cache.

This is exactly what we are trying to do....Keep everything out of L2 and allocate everything for L2 Cache.  I've done this successfully on my DM648 EVM board, but starting DSP Bios exclusively in DDR2 RAM isn't working for us on the DM6437 EVM board.

RandyP said:

You never responded back to my last question from my Oct 16 post. Were you able to reinstall and find the EVMDM6437 and TMS320DM6437 selections for the emulator selections?

Sorry, Thomas had to move on to other projects, and I have been at this company for a week now.  Yes, we are using the same evmdm6437.gel file in both the cc/gel directory of CCS3, and a copy of this GEL file on the <CCS install dir>\ccsv4\emulation\boards\evmdm6437\gel\ directory.

I will try the copy of the .gel file you have attached, but our problem does not appear to be DDR2 memory access related.  Other than the problem somewhere in GBL_init, everything including Code Composer seems to have no problem with the DDR memory.

A couple of notes on the .gel file we are using (obtained from the EVM Tools for the DM6437 Tools CD):

--The Power ALL State menu section does not really control the PSC as I would expect.  This did cause DSP power up problems on the Board whenever the Emulator was reconnected to the Target.  On my version (not attached), I rewrote that section and that cleared up our DSP reconnection problems with the Emulator.

--Setting the Correct DSP Boot Address to the DM6437 Bootaddress Registers also help clear up some minor startup problems for us as well.

Thanks,

JRasmussen said:

Brad,

Our TMS320DM6437 EVM boards show Rev. G.

Thanks,

Is that the hand-written letter on the board?  Could it be a C?  I'm pretty sure that E is the final revision.  For example, when you click this link it redirects you to the "rev e" page:

http://c6000.spectrumdigital.com/evmdm6437

If you can confirm it's Rev C we may want to look at what changes were made from C -> E to make sure there's not something on the board that would cause this issue.

Brad

The gel file included in your project is very old and has significantly different DDR2 timings for the 162 MHz configuration.  I am able to build and run your project in a simulator (which obviously does not model the DDR2).  So it seems to me that the DDR2 configuration in the gel file is the prime suspect as far as I can tell.  I'm certain that I've run BIOS code completely from DDR2 before so it must be something really fundamental.  Please try the gel file that Randy attached.  It should be a very quick test and I suspect will bring this thread to a close.

Brad Griffis said:

 

Is that the hand-written letter on the board?  Could it be a C?  I'm pretty sure that E is the final revision.  For example, when you click this link it redirects you to the "rev e" page:

http://c6000.spectrumdigital.com/evmdm6437

If you can confirm it's Rev C we may want to look at what changes were made from C -> E to make sure there's not something on the board that would cause this issue.

Hi Brad.  I have just reexamined the Revision Letter on both Boards under a magnifying glass.  It is a handwritten G, not a handwritten C.

I will be trying the .gel file from Randy in a little bit and let you know what the results are.

Thanks,

I asked Spectrum Digital about the Revs and they said the following:

"The current revision of the hardware is rev. G.  The support web still only mentions rev. E likely because there were no significant changes to the board from E to G."

So ok, I believe you. :)

More importantly, have you tried the gel file Randy posted?

Randy & Brad,

I was in meetings all morning so it is only now that I was able to try out the Rev 1.50 evmdm6437.gel file that Randy provided.  It does indeed appear to work just fine with my Code Composer 3.3 and the IWB project (I had posted last Friday).  DSP Bios is now starting up for me in DDR Memory on our Rev. G DM6437 EVM boards.

I just tried the .gel file on Code Composer 4, but I couldn't get the Debugger to come up.  However, I have some other issues to sort out there and no time to pursue CCS4 problems right now.  I can continue on with CCS3.3 for now.

So, it appears that Spectrum Digital switched to another type of DDR2 memory in which just the SDTIMR and SDTIMR0 parameters were changed from the older Revisions of the EVM board?  At least, that seems to be the only significant difference I can spot between my old .gel file which came off the EVM DM6437 Tools CD and the .gel file Randy provided.

Anyhow, thanks for sending the latest .gel file.

James,

Good to hear you got it working. It is very odd that SD would not have shipped GELs for the right board. We will point them to this thread.

If or when you decide to pursue the CCSv4 issues (it is best for new designs), please start a new thread since this one is so long and is answered. When you start the new thread, please send the notifications that we discussed with Thomas and others on the team.

If you would, please pick the post(s) that best answered your question and click Verify Answer on them. This helps future users find answer quickly.

Regards,
RandyP