This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
We are seeing some strange behavior that looks similar between our old eZdspF2812 board and a new board of our own board with an F2810.
We were doing a project with the F2810 which required one of the EVMs channels to run in capture mode. However, the EVM capture simply did not work, despite the fact that it was nearly identical to the example code, and all the register configurations appeared correct for our purpose. After struggling with it, it turns out that the count register had to set equal to zero before the EVM capture was configured and it worked. It sounded a bit odd, but it fixed it. If the engineer cleared the count register in the debugger, it would work when he singled stepped the code, but not otherwise. It sounds a little like possible errata, though it did not show up in the errata sheet. The 2810 was purchased just a few months ago, so it is likely the latest silicon.
I have what looks to be a similar problem with an older eZdspF2812 board. I need to do a timer capture on an incoming PWM signal. Oddly, if I download the code over the debug, reset and run the DSP, the timer capture works perfectly. If I do a cold boot, the data I monitor over the RS-232 just looks scrambled. I realize that such behavior might typically be the difference between running from RAM vs. FLASH, but we run the same configuration whether we are debugging or cold-booting - init code runs from FLASH, runtime code is copied over at boot-up into RAM and run from there.
This sounded similar to what we saw with the much newer 2810 board. However, I was able to confirm that the counter is set to zero in the 2812 code, though it is done much earlier in the init sequence, not right before the other EVM registers are set. I would doubt if it would make a difference.
Obviously, debugging the problem is complicated by the fact that I don't have the problem when I am running the debugger.
Before I begin the head pounding, I thought I might check with the TI community and see if anyone has seen behavior like this and knows a workaround, or know a typical "oh duh" that might lead to this type of behavior.
Fortunately, I am not in a huge hurry to resolve this issue, so I have some time to float this issue before I am forced to start beating my head against the wall.
I have heard it said that a wise man learns from his mistakes, and an even wiser man learns from the mistakes of others. Perhaps others have stumbled down this path before me?
Thank you for any feedback!