• State
  • Locked Locked
  • Replies 18 replies
  • Subscribers 80 subscribers
  • Views 1795 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problems look like lottery, today : breakpoints!

Pierre Augustin
Intellectual 490 points

Other Parts Discussed in Thread: MSP430F417

Hello all,

I need your help : I had some problems with CCS : previously it was a problem with PC ou SP I think because during program execution when I clicked on pause, the execution was lost.

Today, one more strange problem : Friday it was quite working well but today when I try to compile and launch the program (I didn't modify it since friday) with a breakpoint, sometime after or just on the breakpoint a error message appears :

"MSP430: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0x81ba: Could not erase device memory" 


I read a lot on the forum and modify many options in the project properties but it's still the same everytime.


Can somebody help me please?


thanks in advance

  • 0
    Mastermind 7925 points

    Hi,

    1. This is a MSP430 not CCS question.

    2. What MCU do you use?

    3. What emulator do you use?

    Regards,
    Maciej 

  • 0 in reply to MaciejKucia
    Intellectual 490 points

    Thank you for your fast answer :)

    It's a MSP430F417., I'm using CCS but what do you mean by "emulator"?

    The problem appears when the code is running, not when compiling.

    regards,

  • 0 in reply to MaciejKucia
    Intellectual 490 points

    Yes it's the MSP-FET430UIF ;)

  • 0 in reply to Pierre Augustin
    Mastermind 7925 points

    OK, so tools are compatible. If you are using custom board you are most likely experiencing hardware issue. If you are using TI tool please let us know what tool it is.

    Please ensure that you build without any optimization (project properties).

    Regards,
    Maciej 

  • 0 in reply to Pierre Augustin
    Guru 227245 points

    Pierre Augustin said:
    It's a MSP430F417.

    It looks like the FET can connect to the device but the toolchain cannot write the program into memory. A possible reason could be  alow supply voltage. When executing code from flash, the MSP suply voltage can be wuite low, but when writing to it, the required minimum voltage is higher. Also writing causes short periods of significantly increased current. If this causes the supply voltage to drop, the write fails.

    Besides this, there was a revision of the FET firmware (delivered with an earlier version of CCS V5 and the new MSP430.DLL V3) that cause the overcurrent protection of the FET to trigger at a relatively low current. This might too cause the program write to fail. However, this problem has AFAIK been fixed quite soem time ago.

  • 0 in reply to MaciejKucia
    Intellectual 490 points

    MaciejKucia said:
    OK, so tools are compatible. If you are using custom board you are most likely experiencing hardware issue. If you are using TI tool please let us know what tool it is.

    Please ensure that you build without any optimization (project properties).

    Regards,
    Maciej

    In fact for the moment I'm working with a TI experimentation board for doing the prototype because we are waiting for the 1st serie of custom boards.

    The board used at this moment is a MSP-TS430PM64 rev. 1.1

    I will check that, I read the parameters to enter in an another post so I will try this thanks ;)

    Jens-Michael Gross said:
    It looks like the FET can connect to the device but the toolchain cannot write the program into memory. A possible reason could be  alow supply voltage. When executing code from flash, the MSP suply voltage can be wuite low, but when writing to it, the required minimum voltage is higher. Also writing causes short periods of significantly increased current. If this causes the supply voltage to drop, the write fails.

    Yes, we saw some strange signal yesterday for the power supply, depending if it was in standby or not so we put directly an other power supply to the MSP430, I will check if it's better.

    Jens-Michael Gross said:
    Besides this, there was a revision of the FET firmware (delivered with an earlier version of CCS V5 and the new MSP430.DLL V3) that cause the overcurrent protection of the FET to trigger at a relatively low current. This might too cause the program write to fail. However, this problem has AFAIK been fixed quite soem time ago.

    Monday I searched for updates and I updated CCS and FET firmware so I think these problems should be fixed no?

  • 0 in reply to Pierre Augustin
    Intellectual 490 points

    Yesterday I had an other error message "MSP430: Can't Single Step Target Program: Could not single step device" and after this message I had to stop session.

    thank you for your advices

  • 0 in reply to Pierre Augustin
    Guru 227245 points

    Pierre Augustin said:
    Monday I searched for updates and I updated CCS and FET firmware so I think these problems should be fixed no?

    AFAIK, in the current versions this is fixed. IIRC, The issue appeared around the beginning of this year.

    Pierre Augustin said:
    Yesterday I had an other error message "MSP430: Can't Single Step Target Program: Could not single step device" and after this message I had to stop session.

    This may happen if for some reason the FET loses control over the MSP. A reset of the CPU could be a reason. Unfortunately, the diagnostic responses aren't very telling. When the debugger sends a 'halt the target' command to the FET, it more or less gets a 'success' or 'failure' response only, and can then only present a more or less generic error message.

  • 0 in reply to Jens-Michael Gross
    Intellectual 490 points

    Jens-Michael Gross said:
    This may happen if for some reason the FET loses control over the MSP. A reset of the CPU could be a reason. Unfortunately, the diagnostic responses aren't very telling. When the debugger sends a 'halt the target' command to the FET, it more or less gets a 'success' or 'failure' response only, and can then only present a more or less generic error message.

    So in fact we can't really know where the problem comes from because it's a generic error message, that's right?

  • 0 in reply to Pierre Augustin
    Guru 227245 points

    Pierre Augustin said:
    So in fact we can't really know where the problem comes from because it's a generic error message, that's right?

    Right. It just tells you that for some undisclosed ro unknown resason the attempt to signle-step the processor failed. I don't think that it's the fault of CCS. If at all, the FET firmware could provide additional information. But most likely it just detects that the requested JTAG/EEM action failed. Or maybe not even that (because EEM context unexpectedly changed) and all CCS can see is that the requested action didn't have the expected effect.

    I guess an improvement of the EEM would be required for debugging the debugging process :)

  • 0 in reply to Jens-Michael Gross
    Intellectual 490 points

    I didn't really understand but I have now the same problem when the program is going into an interrupt and I'm doing step-by-step...

  • 0 in reply to Pierre Augustin
    Guru 46710 points

    Pierre Augustin said:
    I have now the same problem

    I occasionally had similar problems too. My problem was ground loop noise caused by laptop switching supply. You can try following: In case of laptop just unplug it from mains and run on battery, try debugging. Otherwise try to run circuit from well-isolated supply like batteries, do not galvanically connect circuit to anything except batteries and FET interface.

  • 0 in reply to Ilmars
    Intellectual 490 points

    thank you for your suggestion but I'm using a desktop computer but maybe because of the wiring on the prototype there are some noise coupling, we will receive the firt boards in some weeks so after that I will be almost sure it will be not because of hardware...

  • 0 in reply to Pierre Augustin
    Guru 227245 points

    Pierre Augustin said:
    thank you for your suggestion but I'm using a desktop computer

    Desktop computers too have a switching power supply. Also, in opposition to most external laptop supplies, the desktop is often grounded too. This may even increase the problem.

    One of my older desktops did have a noticeable leakage voltage. If you touched it, you could notice a prickle. Not dangerous for humans, but surely dangerous for attached electronic equipment.

  • 0 in reply to Jens-Michael Gross
    Intellectual 490 points

    How I could prevent these problems caused by the computer power supply? with ferrite?

  • 0 in reply to Pierre Augustin
    Guru 227245 points

    Pierre Augustin said:
    How I could prevent these problems caused by the computer power supply? with ferrite?

    No. Only by not having two sides of a connection connected to different GND potentials.
    That means
    1) break the connection by using an isolating USB cable (expensive, but a really good thing)
    2) use a safety transformer to plug your target supply into (it will be pontential-free then)
    3) use a plain old transformer-based supply (not a switching one).
    4) power the target from battery
    5) power the target from the same PC (e.g. separate USB slot, or even a 5V or 12V supply cable - there are 3.5" frames with fused 5V/12V power plugs)

  • 0 in reply to Jens-Michael Gross
    Intellectual 490 points

    Jens-Michael Gross said:
    No. Only by not having two sides of a connection connected to different GND potentials.

    That means
    1) break the connection by using an isolating USB cable (expensive, but a really good thing)
    2) use a safety transformer to plug your target supply into (it will be pontential-free then)
    3) use a plain old transformer-based supply (not a switching one).
    4) power the target from battery
    5) power the target from the same PC (e.g. separate USB slot, or even a 5V or 12V supply cable - there are 3.5" frames with fused 5V/12V power plugs)

    In fact on one side I have the usb cable connected (USB 2.0 certified, not a cheap one) and on the other side the power cable plugged on the main board.

    The guy who works on electronics checked the circuit.

**Attention** This is a public forum