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.

TMS320F2808: Program Counter in reserved memory

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.

Regards, Giles

  • Giles,

    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.

    Regards,

    Richard

  • Richard Poley said:
    The 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.