• Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 807 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Msp-exp430fr5739 (experimenter board) - ADC10-SC bit

7ACDRIVER
Intellectual 400 points
Other Parts Discussed in Thread: MSP430FR5739The user guide covering MSP430fr5739 (SLAU144) describes ADC10SC bit (of ADC10CTL0) as r/w, but I can never catch it as '1' even when putting a breakpoint at the next instruction after setting it. This leaves the question of the possibility of getting an invalid-or at least unexpected- answer when testing for this bit. The question may be academic, but it goes to how the CCS4 debugger works. The conversion proceeds as expected, so prima facia evidence suggests that it is being set -just that the debugger won't show it or it is being reset at the completion of the conversion. The setup is for a single conversion with interrupt enabled. Any explanations?
  • Guru 227245 points

    7ACDRIVER said:
    but I can never catch it as '1' even when putting a breakpoint at the next instruction after setting it.

    If you'd try to catch a salmon with a debugger, it would be rotten long before you would see the catch in the debugger window.

    In other words: the ADC is analog hardware. It is completely unimpressed by the debugger and its power over the CPU core. The debugger stops the CPU, but the rest of the world, including the ADC, keeps turning. So when your debugging software finally requests the content of this register (including the ADC10SC bit), this bit has been updated by the hardware centuries ago.

    It's a common mistake amongst newbies to the microcontroller world, that they expect the debugger to freeze the whole realtime world. No, all the debugger can do is stopping the progress of the code (and maybe ACLK/SMCLK too). Everything else continues. Including input signals, radio waves, interface bit timings etc.

    In other words: the debugger is the right tool to check the code, but it is the wrong tool to check anythign that is related to code-flow-independent things. For this kind of things, a logic analyzer or a digital scope are by far the superior tools.

    7ACDRIVER said:
    or it is being reset at the completion of the conversion

    Exactly. That's it. And the conversion is complete loooong before the debugger has even sent the request for the register content to the MSP through the high-latency USB connection.

**Attention** This is a public forum