Yu Lui,

Does the PPC crash at the same point each time it crashes? What causes it to crash?

What are the C6416s executing on the slave boards when the PPC crashes?

How are the C6416s booting?

If they work correctly sometimes, what can be different on the occasions when it crashes?

Regards,
RandyP

RandyP

Thanks for your attention to my post. the PPC crash does not  occur every time, but the appearance of crash is the same: When host write data or read data to or from slave by PCI in first time, the process will fail and the PPC will crash. When crash occur, the C6416s on the slave board executed nothing, which is meaning, the the host board just visit the C6416s' L2 Memory by PCI,  whereas the slave boards don't run any code, even don't connect the emluator. C6416 just have powered up.

By the way, today when we check the hardware of slave boards, we find one slave board 's  BEA8 and BEA9 pin are externally pulled up with a 10-kΩ resistors by mistake, rather than 1-kΩ  resistor.  The frequence of crash occuring when PPC communicates with this slave board is  lager than that when PPC communicates with other slave board.  so I want to know, if the 1-kΩ  resistors will affect the C6416, and what is the function of the two of  1-kΩ  resistors 

Regards,

Yu Liu

Yu Liu,

My apologies for making you do the work, but I will make you do the work here.

I do not want to guess or assume, so I will ask what is the boot mode used for the slave boards?

What are the functions of the BEA8 and BEA9 pins?

When a pin has an internal pull-down, we recommend a strong pull-up (1kΩ) to oppose that internal feature. A weak pull-up (10kΩ) can be used to assist an internal pull-up.

Do the BEA8 and BEA9 pins have internal pull-downs that you are trying to oppose? If so, the weaker value could be causing an intermittent failure to enter some mode determined by these pins.

Regards,
RandyP

RandyP

I apologize for not illustrating the slave boards boot mode. The  boot mode of the two slave boards are both 8-bit flash boot mode.  However, I am confused why you concentrated on the boot mode of slave boards. If the different boot mode will bring different status leading to crashing of host. But during the test, the emulator is also used, the host will crash  as of old. 

The BEA8 and BEA9 is connected as the data sheet (choose 1kΩ  pull-up). However the crash will appear as of old, just the frequence of appearing is less. 

Now, I read the data sheet carefully, I find the PCI and L2 is connected by EDMA , which means, the data communication between L2RAM and host connected to PCI will go through the EDMA. As a result, If the reason of crash is made by slave board, I doubt if I need configure the EMDA first?  

Furthermore, I use L2 as RAM rather than cache(I don't operate the L2 registers, all use as default value ). If I need configure some L2 registers?

I'm look forward your suggestion. 

Regards,

Yu Liu

Yu Liu,

Yu Liu102004 said:

I am confused why you concentrated on the boot mode of slave boards.

You are completely knowledgeable of your boards and system and what is running on the DSPs. I am not. So I must ask about different things that could affect the issue you are seeing. For example, if you were using PCI boot mode, then I would immediately understand why you say "the slave boards don't run any code" since the PCI peripheral would hold the DSP internally in reset. But since you use 8-bit Flash mode, the slave boards are running code unless you are holding the DSP in reset by the pins. Is this the case? Are you holding reset active or does the DSP boot from the 8-bit Flash successfully and is therefore executing the code loaded by the bootloader?

Yu Liu102004 said:

The BEA8 and BEA9 is connected as the data sheet (choose 1kΩ  pull-up).

You no longer have a question about using 10kΩ instead of 1kΩ pull-ups. You are only using the correct 1kΩ pull-ups, by my understanding now.

Does your boot code and your loaded program do any initialization of the PCI peripheral in the C6416?

You should check all of the pull-ups and all of the boot-time pins, such as PCI_EN to make sure they are handled correctly.

What is the nature of the crash on the PPC?

Does the DSP continue running successfully? What is it doing in the code loaded from the 8-bit Flash? Is it waiting for something from the PPC?

Do you have bus analyzer equipment so you can watch what is happening on the PCI bus to determine what has occurred between the PPC and the C6416?

Why do you suspect the problem is in the DSP when the PPC is crashing? I do not doubt your understanding, but it is not clear why this is your suspicion.

Regards,
RandyP

RandyP,

I apologize for long time missing your reply because of my business trip. For making you understand my problem and system more detailedly, I will illustrate more detail.

The system we designed has three boards: one master control board(A for short) with MCU PPC, and two slave business boards(B,C for short) with MCU C6416T. Three boards communicate by PCI bus. The PPC runs the OS VxWorks 5.5, and the A board plays as master device. Both the two slave business boards play as slave devices. for testing the hardware communication channel, we have done the test in below ways:

1. we control the PPC to write 32 same words data to B and C board.For simple, we use the default value on DSPP.PAGE 0, and set the destined address of writing as base0+0x10000,which means the PPC will write the 32 words data to the start address 0x10000 of C6416 L2 memory.
2. The C6416 boot mode in both B and C boards are 8-bit flash.In the flash, there are the same code whose function are to receive and check the 32 words data at 0x10000 from host board. For test, we arrange PPC send 32 same words data 0x1234ABCD, and in B and C,we check the received 32 data if are all 0x1234ABCD.If the check pass, we will set the LED on A and B board light.
3.Now during the test, we find the phenomena occasionally that when PPC write the data to B and C, B or C will hold the PCI bus all the time, the PPC's writing process stop. We test some control signal of PCI bus the PFRAM and STOP appear ceaselessly, but the TRDY signal null. We supose the OS in PPC have crashed, but when we reset A or B, the PPC writing process will continue. On the other hand, if we reset the A board rather than B or C, and we write data to the slave board which hold the PCI bus all the time again, the slave board will hold PCI bus all the time again, the above phenomena will appear. As a result, we think the problem is on the side of slave boards.
So, I wish you can give me some suggestion.

Hello Chris,

I apologize for not replying your post for a long time. The 6416 PCI lockup issue have not been resolved. Furtermore, it will also happen on 6205. 

I wonder whether you have resolved this problem? 

And the appearance of the problem is indeed as you say, but i am curious why the FIFO' s not being flushed is related to power-on sequencing.  I think that if the reason is the power-on sequencing, the appearance will appear during the 6416 power up, however, in our experiment, the appearance will appear during the PCI communication  processing, that means the 6416 will firstly work well, and then fails, which seems not relate to power-on sequencing. 

Please let me know your opinion

Thanks,

Yu

Hello Yu,

Thank you for getting back to me. Unfortunately, we have not made any progress on this issue. We have a number of products that use the 6412, and a small percentage of every product exhibits the PCI lockup issue.

Our symptoms sound similar to yours. Upon power-on, we can send a few words of PCI traffic (~16) and then the lockup occurs (when the PCI FIFO overflows). Is this what you are seeing where lock-up always occurs after a few PCI transactions? Or does your lockup occur randomly at any time?

We further isolated the behavior to occur more or less frequently depending upon the power-on timing and temperature. As I mentioned before, this issue occurs on a small percentage of each production run. 

I hope this helps. Please let me know if you find anything. I will do the same, and post our results here.

Best regards,

Chris

Hello Chris

I 'm very glad to receive your email though both of us don't resolve this issue.  In our experiment ,  the lock-up occured randomly:

some time it occured when the host device read or writed internal memory of slave device firstly, some time it occured  after  long time PCI transactions, some time ti occured frequently, and some time it occured in a small percentage. As a result, I really can't find the regular pattern. 

As you say,   the power-on timing will bring the influence, however, I think if this is true, the lock-up will only occured at the beginnig of the  PCI transactions. This is my doubt. 

Now I am concentrating on this problem, if I have some find, I will make you konw, and so do you.

Best regards

Yu