BIOSPSP code doesn't run

James Jurack

Other Parts Discussed in Thread: OMAP-L138, OMAPL138

I am trying to get going with BIOSPSP on C6748; In particular I am trying to run the edma version of the SpiSample example code. The first time I ran it, it seemed to work properly. But now, it seems to do nothing at all.

I have added a breakpoint at the start of every function in the code, and it appears that only the SpiUserInit function is every executed. If I let the DSP run after that, it seems to hang without doing anything. If I then pause execution, it seems to be stuck at "0x1181B0F0: 00034000 SPKERNEL 0x 0" forever.

Sometimes, I can't even get to the breakpoint in SpiUserInit, and, in fact, all of my breakpoints have been automatically disabled. Trying to enable them at run-time yields the message "'C:\.....spiSample.out' must be loaded to resolve 'C:\....spiSample_main.c' line 111 to an address," even though this is precisely the .out file that I have loaded and am executing.

I've also had a similar problem with the uartSample example.

over 15 years ago

0 AC2150 over 15 years ago

TI__Intellectual 2605 points

hi James,

Dbl-check your PSP version - latest is http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/01_30_01/index_FDS.html

In particular pay close attention to the Dependencies section in relnotes - there's a tight relationship w/ EDMA3 low level dvr version (and to a slightly lesser extent BIOS & CGT tools versions). We've seen similar issues to above when there is component-dependency-mismatches.

Hope this helps.

Cheers, Alan

0 James Jurack over 15 years ago in reply to AC2150

Intellectual 390 points

I do have PSP 01.30.01, however its manual states it requires EDMA LLD >= 01.11.00.03, but I can only find up to 01.10 available on ti.com (here: http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/psp/edma3_lld/index.html#DSPBIOS_5.3x_based_EDMA3_LLD_Downloads).

0 Mariana over 15 years ago in reply to James Jurack

TI__Mastermind 24340 points

Hi James,

Please see:

http://processors.wiki.ti.com/index.php/GSG_C6748:_Installing_the_SDK_Software

The GSG points to the "readme first card". There you can find a link to the SDK software:

www.ti.com/omapl138c6748sw

If you install C6748_setupwin32_1_00_00_11.exe or OMAP_L138_setupwin32_1_00_00_11.exe , the correct version of EDMA 3 will be in there.

0 James Jurack over 15 years ago in reply to Mariana

Intellectual 390 points

I've got the most up-to-date EDMA LLD now (and I've confirmed that it's in use by looking at the build log (--include_path="C:/Program Files/Texas Instruments/edma3_lld_01_11_01_04/packages").

No change in my problem, though.

0 James Jurack over 15 years ago in reply to James Jurack

Intellectual 390 points

Some additional information I discovered after playing around with the SpiSample some more today: the stack trace includes the name of the function I'm stuck in:

spiSample [Debug] - Texas Instruments XDS100v1 USB Emulator_0/C674X_0 [Project Debug Session]

Device

Thread [main] (Suspended)

0 PMI_writeI2C(unsigned int, unsigned int, unsigned int) at pmi_i2c.c:192 0x118170f0

Texas Instruments XDS100v1 USB Emulator_0/C674X_0 (4:23:25 PM)

Texas Instruments XDS100v1 USB Emulator_0/C674X_0: CIO (4:23:25 PM)

Finding pmi_i2c.c in my BIOS distribution, it looks like the relevant chunk of code is:

/* wait for TX ready status */

{

status = REG(ICSTR) & ICXRDY_BIT;

}

while (status == 0);

0 AC2150 over 15 years ago in reply to James Jurack

TI__Intellectual 2605 points

bit of a wildcard...make sure you have the right GEL file.

Also check out http://processors.wiki.ti.com/index.php/How_to_connect_to_the_OMAP-L138/C6748_EVM_board_using_CCS%3F

Cheers, Alan

0 Mariana over 15 years ago in reply to James Jurack

TI__Mastermind 24340 points

Hi James,

Are you using the OMAP-L138 SOM or the C6748 SOM?

0 Ben Fitzpatrick over 15 years ago in reply to Mariana

Prodigy 40 points

Mariana said:

Hi James,

Are you using the OMAP-L138 SOM or the C6748 SOM?

Mariana,

We are using the C6748 SOM. I am working with James on this issue.

Thanks,

Ben

0 Mariana over 15 years ago in reply to Ben Fitzpatrick

TI__Mastermind 24340 points

Hi Ben,

Can you test with the OMAP-L138 SOM? This way we could check if there is a hardware problem in the SOM.

Please make sure that you make the connection inserting the GEL files as described at:

http://processors.wiki.ti.com/index.php/How_to_connect_to_the_OMAP-L138/C6748_EVM_board_using_CCS%3F

0 Ben Fitzpatrick over 15 years ago in reply to Mariana

Prodigy 40 points

Mariana said:

Hi Ben,

Can you test with the OMAP-L138 SOM? This way we could check if there is a hardware problem in the SOM.

I think I can set this up later today. I will need to wait until someone on my team with access to the LogicPD site comes in so I can get the proper GEL file from them.

0 Mariana over 15 years ago in reply to Ben Fitzpatrick

TI__Mastermind 24340 points

Hi Ben,

Let me know when you can test it then.

Also, anyone can get the logic files, you need an account (just register) in their website (no need to register a board) and then click in the BSL links below.

http://www.logicpd.com/products/development-kits/zoom-omap-l138-experimenter-kit#tabs-som-2

Also, if you have a more detailed description of what is happening it would be good.

0 TimHarron over 15 years ago in reply to James Jurack

TI__Mastermind 18130 points

James,

James Jurack said:
Some additional information I discovered after playing around with the SpiSample some more today: the stack trace includes the name of the function I'm stuck in:
spiSample [Debug] - Texas Instruments XDS100v1 USB Emulator_0/C674X_0 [Project Debug Session]
Device
Thread [main] (Suspended)
0 PMI_writeI2C(unsigned int, unsigned int, unsigned int) at pmi_i2c.c:192 0x118170f0

This is a known issue caused by an errata which seems to occur randomly on SOME L138/C6748 SOMs. There's a somewhat lengthy discussion detailing this issue (as well as a link to the errata page) in this other post. From what I can remember, if you dynamically scale the core voltage to 1.0V this causes the PMI_writeI2C function to lock up.

0 James Jurack over 15 years ago in reply to TimHarron

Intellectual 390 points

Thanks for the info, Tim! Do you know if I can modify my .gel, etc, to change the voltage scaling? Or do you think the board rework that the errata doc suggests is a better solution?

0 James Jurack over 15 years ago in reply to James Jurack

Intellectual 390 points

Well, we tried the board rework suggested in the errata document. Looks like it had absolutely no effect on the problem, though -- we're still getting stuck on PMI_writeI2C().

0 James Jurack over 15 years ago in reply to James Jurack

Intellectual 390 points

We've now tried using the OMAPL138 SOM instead of the C6748, and the problem does not occur.

We are planning on using the C6748 in our final design, however. Is there any other known issue with this SOM, since the errata workaround did not solve our problem?

... and now, after switching back to the C6748 again, spiSample is working, but only if I step through it. Otherwise it gets stuck on "FXN_F_run() at fxn.s62:72 0xc00266a4", if I let it run free between a GIO_write() and a Spi_FlashIsBusy().

0 Mariana over 15 years ago in reply to James Jurack

TI__Mastermind 24340 points

Hi James,

Tim and I could not reproduce exactly what you are experiencing, so can you make a test for us?

Reset the board, plug the C6748 SOM, open the project that you are having problems, go to the tcf file. Expand System, right click on the PWRM module, choose "Properties", and uncheck the "Enable PWRM Manager" box. Do a "Rebuild all" in your project. Let us know if it helps.

0 Mukul Bhatnagar over 15 years ago in reply to Mariana

TI__Guru* 83885 points

Another long shot , even though seems like most of the usual suspects for this type of issues have been tested and ruled out.. are you making sure that when you use the c6748SOM , you have the right GEL files to put the device at 1.2V/300 MHz. Typically when debugging with the OMAPL138 SOM, you would do this setting from the ARM side GEL file (setting up the device at speed), when you are using c6748 SOM, you would need to make sure that the DSP gel file configures the c6748 to 300 MHz correctly.

Regards

Mukul

0 James Jurack over 15 years ago in reply to Mukul Bhatnagar

Intellectual 390 points

This went away on its own for a while, then came back recently. Another engineer here suggested disabling V/F scaling, and that solved the problem.

Processors

Processors forum

BIOSPSP code doesn't run