mcbsp with Edma

majid mechael,

majid mechael said:

i have some problems in some of the boards (evm320c6474)

This implies that you also have some boards that do not have this problem. Is that correct, or does it happen on all of the boards? How many boards?

majid mechael said:

when i run the Mcbsp_Edma_example  example its run ok for the first time but if i try to run it again it will not work it freazes at this comman "while (!rxintFlag);"

What are the exact steps that you run to see it run ok, and to see it freeze? For example,

1. Power to the board.
2. Start CCS
3. Connect CCS to one core on the board (which one?)
4. Compile/build the program
5. Load the program to the DSP core
6. Run the program and it runs ok (for how long? as long as you let it run?)
7. and then what do you do?

majid mechael said:

i did the reset gel  before i compile .

and i see also if i push the SW3 button on the boards the example will run again for one time only

Are you saying that both the GEL_reset command and the SW3 button will reset the board and the example will run ok again?

majid mechael said:

what i want to know if am doing something wrong when runnig the example or there is something wrong with the board

If you sent the board for repair and TI said it was okay, this says there is nothing wrong with the board.

The most likely answer, without knowing the answers to my questions above, is that the example is not intended to re-run the way that you are using it. My guess is that when you stop the program, some McBSP or EDMA3 error conditions are created and that these error conditions are not fully cleared by the software in the example. Resetting the board takes care of this and the example will run once again.

The example shows you have to make things work, and it achieves that goal quite well. The example may not be intended to be fully robust and to erase every possible error condition that could remain or to halt every peripheral that might be running. The example likely assumes that you have just reset the board, so you would need to reset the board each time.

In many cases, the GEL scripts include automatic reset functions when loading a program.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

hi RandyP and thank you for your reply

we have already more than 20 boards (evm320C6474) just three of them are having this proplem.

the setps for the test are

• Power to the board.
• Start CCS
• Connect CCS to the second core
• Compile/build the program
• Load the program to the DSP core
• Run the program it will run and output the right output
• go to gel and reset the board
• Compile/build the program
• Load the program to the DSP core
• run the program it stuck ;

do the last 4 steps as alot of time and still getting the same result

but if i push the SW3 button which  found on the board and do the 4 steps again it will run perfectly only one time

note ::the gel file loaded is the one for this board

i tried this test on working board and it worked all the time

Best regards ,

Mechael majid

Mechael majid,

Does it behave the same way if you connect to the first core? The first core tends to be the primary core since it is tasked with releasing reset from the other cores in some boot modes. There is no clear reason why it would behave differently just because of the core being used, but it would be an interesting datapoint.

majid mechael said:

we have already more than 20 boards (evm320C6474) just three of them are having this proplem.

It is impressive that you have this many of these EVM boards and that you would try running this example routine on them all. These are very powerful boards, and I hope you do not run into many more problems with our example programs.

For your reference, you can download CCSv4 to use with the direct USB emulation on this EVM. There will be no license fee for using CCSv4 with the EVM's on-board emulation or with the C6474 simulator. If you use an external emulator for faster emulation, then there would be a licensing fee per station. There are only a few drawbacks to using CCSv4, mainly that some of the BIOS real-time tools do not operate as well; this is being fixed in CCSv5. But for multi-processor debug, CCSv4 is a huge improvement over CCS 3.3. For me, I could rarely have more than 3 core debug sessions running in CCS 3.3, and that required shutting everything else down on my PC, and even then CCS would crash from time-to-time. With CCSv4, multi-core and multi-device debug is much simpler and only requires a single instance of CCS to be running. Just something to consider for the future, if you are interested at all.

Since you have a this problem only on certain boards, a good guess would be that an external component is not getting a full reset unless you use SW3. I have no explanation why this would be different from one board to another, and this is a debug task that you may not want to take on. The solution of using SW3 before running this example is not an extreme hardship, and it could take a lot of hours of debug to find out which device or which register needs to be re-initialized.

majid mechael said:

do the last 4 steps as alot of time and still getting the same result

but if i push the SW3 button which  found on the board and do the 4 steps again it will run perfectly only one time

The external devices on the McBSP port may have internal registers or states that require a hard reset to start again. There could be register-based resets that you can use, if you want to look that direction for a solution.

The EDMA has registers that are not routinely cleared by the open/init process, in particular the EMR and SER registers which could keep a DMA channel from operating. You can look at these before running a second time to see if they are part of your problem.

The McBSP may still be running, along with the external device, when you stop and try to re-run the program.

All of these will be difficult debug, but by studying the associated User's Guides and Device datasheet, and looking through each register at the appropriate times, plus watching the McBSP signals on an oscilloscope or logic analyzer, you will be able to track it down and find what registers need to be explicitly initialized to be able to run again.

Of course, this assumes my guesses are right. But with this many boards, this means you have a lot of engineering eyes and hands who could help with the process and lead the effort. Please report here with any successes you have.

Or maybe someone else has solved it and will speak up with that solution. My recommendation would be to just use SW3 and move on to the next task.

Regards,
RandyP