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.
Part Number: TMS320F2808
We are using this a TMS320F2808 in a bespoke card, with various external power supplies.When the only inputs are 3V3 and 1V8 to power the processor, all seems to be OK. My code is running.If I then turn on another power input to supply other components on the card, something goes wrong. On pausing in the debugger, sometimes the code has jumped to my “unexpected interrupt” handler, but often the program counter is somewhere in the reserved memory between 0x00C000 & 0x3D7800. I try restarting / resetting and can step through the code, but as soon as I run it the same thing happens.Strangely, if I stop debugging, and toggle the reset line, the code runs successfully – as seen by toggling a GPIO. However it is quite likely to stop working, probably jumping to the interrupt handler or reserved memory again.Anyone know what sort of thing causes this behaviour? Clearly something is happening on the card which is specific to the card, and we have to track that down here. But perhaps someone can provide a clue. I don’t yet know which interrupt is actually calling the handler, but will be looking at that shortly.
Very likely you have a glitch on one or both of the device power rails when you switch on the other supply. Monitor the rails very carefully with a 'scope to ensure both are clean and remain within datasheet limits. The PC being corrupted is typical of that and the address would be non-deterministic.
If you're sure the power is clean, it will be a matter of proceeding methodically, looking at each pin as you enable the other rail. Look also for any source of radiated noise, such as a power supply transformer. You may be able to temporarily replace the supply with a bench PSU to see if this makes a difference.
Impossible to be specific, but this is where I'd start.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Richard Poley:
Richard PoleyThe PC being corrupted is typical of that and the address would be non-deterministic.
Thanks, that's useful to know. I'll mark issue as resolved as, although I may have a lot of work to do alas, there are probably no more questions.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.