C6455 SRIO LSU Not Working After SRIO Boot

So, something is different between what you are doing on the EVM and on your own board.

It would appear that the SRIO peripheral is initialized and the PHY is active since you get the PORT OK, but there should be some response once you write to LSU5.

Since there is not a response of any kind, the implication to me is that the SRIO is not in a fully active state.

The fact that you brought the DSP up in SRIO boot mode but did not complete the SRIO boot, this makes me think that you are holding the DSP in a bad state.

Can you change the boot mode to No Boot and just use the emulators to initialize the SRIO and run the test, which is probably what you were doing on the EVM. Or complete the SRIO boot, if that is what you were doing on the EVM.

RandyP said:

Since there is not a response of any kind, the implication to me is that the SRIO is not in a fully active state.

Agreed! It just seems strange to me that it could be partially active.

RandyP said:

The fact that you brought the DSP up in SRIO boot mode but did not complete the SRIO boot, this makes me think that you are holding the DSP in a bad state.

Well the SRIO boot loader is running, so I guess the DSP should okay at first. Then I connect the emulator in real-time mode and load some code but I don't know precisely what happens when a program is loaded so I supposed the DSP could end up in a "bad state".

RandyP said:

Can you change the boot mode to No Boot

No, unfortunately the BOOTMODE pins are hardwired on our board.

RandyP said:

Or complete the SRIO boot

I'll try completing the boot from the host and then connecting the emulator. Or maybe creating a test program that I can load from the host; although providing feedback without the emulator could be tricky, there's only one LED.

Thanks for taking an interest, it helps to talk!

I've been looking at something else today but I will return to this on Monday.

Thanks,

Matt

I still haven't got my our board working but today I've been using the EVM6455 to investigate SRIO.

Here's what I've done:

• Switched both the DSK and Mezz to SRIO boot
• Power up
• Connect the debugger (not real-time mode)
• The program counter always appears as 0x001011ec which I assume is the idle loop in the SRIO boot loader
• Drive LSU1 from the watch window
• The LSU appears happy enough and I can see data arriving at the destination

If the packet type is NWRITE then the addresses (REG1 and REG2) increment by the byte count and the byte count (REG3) goes to zero. I don't see any change to REG6, I assume it indicates busy for less time than it takes the debugger to read what's in the watch window.

If the packet type is NWRITE_R the addresses and byte count will only change if the transaction is successful. It is usually possible to see REG6 indicate busy. If NWRITE_R is unsuccessful, possibly because the destination id is incorrect, then the addresses and byte count do not change and REG6 will indicate transaction timeout.

Unfortunately I'm not sure how any if this helps me but I thought it was interesting that it's possible to drive the LSU from the watch window.

Have you tried the exact same procedure as above on your board?

Have you tried completing the SRIO boot on your board and then running the test program?

RandyP said:

Have you tried the exact same procedure as above on your board?

Yes although different emulators and different target configurations. I removed the gel files from all my target configurations hoping that this means that all configuration (PLLs, device config, etc) should be just as the bootloader sets it.

I've just noticed that my EVM6455 has a different bootloader version. My EVM is a bit old, it has bootloader V2.2 while my board has V2.3.

V2.3 has the idle instruction at 0x001011cc.

RandyP said:

Have you tried completing the SRIO boot on your board and then running the test program?

I thought I had but I've already forgotten what I did this morning! :-}

I think tomorrow I will try doing a complete boot from the host i.e. download the code over SRIO and send the doorbell. I'll have to find a special way of flashing the LED to tell me what's happened!

Obviously I've found it unnecessary to complete the SRIO boot (i.e. receive a doorbell) on the EVM.

Thanks,

Matt

Okay, so I still haven't done what I said I was going to do (complete the SRIO boot with a doorbell) because things are getting stranger!

I now have 2 EVM6455s which are not the same. The EVM6455 which I have been using up until now is old and fitted with TMX320C6455-D11 (i.e. pre-release and silicon revision 1.1). This morning I acquired a newer EVM6455 which is fitted with TMS320C6455-$N20 1GHZ (i.e. silicon revision 2.0).

When I tried the newer EVM6455 it appeared to behave like our board i.e. I couldn't do an NWRITE(_R) after a SRIO boot (Configuration 0) so I'm no longer using our board.

I have stopped using SRIO Boot and selected NO_BOOT on all EVM boards. My target configuration includes the DSK6455 gel files.

I have created 2 SRIO initialisation functions; 1 is supposed to configure 1x/4x mode (this is what I have been using and is taken from various examples) and the other is supposed to configure 1x/1x (single port/single lane) mode. On our board we are selecting SRIO Boot Configuration 0 which should be 1x/1x.

My test procedure is:

1. Disconnect the debugger
2. Reset the boards using the reset switch
3. Connect the debugger (PC appears as 0x800000)
4. Load test program
5. Run test program to completion of InitialiseSrio
6. Exercise the LSU using the watch window

This works fine for 1x/4x and 1x/1x on the old EVM with silicon revision 1.1.

This does not work on the newer EVM in 1x/1x mode but does work in 1x/4x.

I'm still confused by the SRIO initialisation process so I hoping that I'm doing something wrong but I'm somewhat worried that I appear to be getting different behaviour from different silicon revisions.

I've attached the file that contains 2 (conditionally compiled) versions of InitialiseSrio.

This example is a bit of a mess because it is a hodgepodge of various examples I've been working on. I shall create a new project to hopefully create a clearer example of what's going on!

In the meantime any thoughts greatly appreciated.

Thanks,

Matt

Matt,

I will push your issue around TI on the differences between the two revisions. If the silicon or boot ROM or EVM boards changed, we should be able to tell you. What are the board revisions that pair up with the silicon revisions you listed?

If the silicon changed, then the ROM code would also change for the SRIO boot mode to be able to implement those.

Your continuing debug on the differences between the EVMs will be helpful to us, to point out exactly what is behaving differently. But it will not get you to a project solution.

So I still recommend completing the SRIO boot, and then try the watch window and the program tests on the LSU. If that does not work, then we have a problem worse than debugging init code.

RandyP

RandyP said:

Your continuing debug on the differences between the EVMs will be helpful to us, to point out exactly what is behaving differently. But it will not get you to a project solution.

So I still recommend completing the SRIO boot, and then try the watch window and the program tests on the LSU. If that does not work, then we have a problem worse than debugging init code.

Yes, agreed. I'll try it on the EVMs which will be a lot easier than our hardware.

Thanks,

Matt

Good find.

Does this solve your original problem, or just the variation between the old and new silicon?

RandyP said:

Does this solve your original problem, or just the variation between the old and new silicon?

This solves my original problem and I think explains why I was seeing different behaviour and got in a bit of a muddle.

I've set MASTER_ENABLE on our board and I believe the transactions are actually being sent because I now get an error completion code if I do NWRITE_R.

All I need to do now is understand how to configure the FPGA correctly! :-}

Thanks for asking,

Matt