MSP-FET cannot always set breakpoints

Pedro, Andreas,

The errors you are seeing may be related to this thread. I will move this thread to the MSP forums where the experts there can help you best. 

Hello AartiG ,

the Thread Page does not exist.

Many Thanks

Andreas Beranek said:

the Thread Page does not exist.

Sorry about that. I fixed the link.

i tried the Downgrade. But it faails:

*****************************************************************

   WARNING

   Do NOT run this downgrade utility with more than one emulator connected.

   Multiple connected MSP-FET430UIF or eZ430 emulators may cause the downgrade
   to fail and render the interfaces unusable.

   Please ensure to disconnect all interfaces except one MSP-FET430UIF.

******************************************************************

Enter 'y' to confirm: y


   Initialize: done
   MSP430_FET_GetFwVersion()
   Firmware Version: 30700011
Status: Starting firmware update with 'Uifv3Downgrader.txt'!

   Initializing bootloader...
   Programming new firmware...
   100 percent done
   Update complete.

   100 percent done

   Finishing...
   Initializing bootloader...
   Programming new firmware...
   100 percent done
   Update complete.

   100 percent done

   Finishing...   100 percent done
   Update complete.

   100 percent done

   Finishing...Error, firmware update failed during load of V2 core and EEPROM image


  Press any key to close this application.

HW?

Hi, 

Nice to see that I'm not the only one with this problem.

I can confirm identical behaviour to everythin that Andreas has said, It really looks like the same issue definitely.

I have tried both batch files, and I get identical result as Andreas. In the same way as moshe on the other thread, when I run the V2V3, it finishes correctly, but I still experience the wrong behaviour regarding the breakpoints that moshe has seen.

I have done this with two different MSP-FETs and they do exactly the same thing.

I have not gone into the last suggestions on the other thread because my debugger is not a FET-430UIF.

Quite annoying, indeed.

Hi moshe,

I had the same feeling, it looks like the debugger thinks the memory map is a different one. But there is a case that speaks against this possibility, the first breakpoint send to not have any limitation regarding address, it is only from the second breakpoint that there is this problem.

I believe more people must be having this problem too, but didn't find time to write, or are waiting for other people to write about it, I guess.

Nice tests you are doing by the way. let's see if we get this fixed as soon as possible and we can get back to work.

best regards,

Hello All,

i tried again both Batch Files. Both fail with an Error

   Initialize: done
   MSP430_FET_GetFwVersion()
   Firmware Version: 0
Status: Starting firmware update with built in image!
Error, firmware update returned an error

Unfortunately i have no second FET

Many Thanks,

Andreas

Pedro Perez de Ayala, Andreas Beranek, moshe jacobson18,

I just tried to see if I could replicate the issue that you seem to be having but was not able to do so (I tried using CCS versions 6.1.2.00015, 6.1.1.00022, and 6.1.0.00104). I am using the MSP430G2553 with the MSP-FET in debug mode. I tried setting multiple breakpoints and also tried stepping through my code with no issues. 

Could you please report the following information:

• CCS Version (Help --> About Code Composer Studio)
• Compiler Version (Right click on Project --> Properties --> General)
• MSP430.dll Version (Navigate to the installation folder and go to ...\ccsv6\ccs_base\DebugServer\drivers --> Right click on MSP430.dll --> Properties --> Details)

Can you try creating a new project with some example code to see if you still have the issue when doing that? Also, can you try reinstalling CCS and import your project to see if that fixes the issue?

Regards,

Akash Patel

CCS Version:  Version: 6.1.2.00015

Compiler: TI v4.4.7

Linker Command File: lnk_rf430frl152h.cmd

MSP430.dll: 3.7.0.11

I created the default Assembly Project without modifications:

;-------------------------------------------------------------------------------
; MSP430 Assembler Code Template for use with TI Code Composer Studio
;
;
;-------------------------------------------------------------------------------
            .cdecls C,LIST,"msp430.h"       ; Include device header file
            
;-------------------------------------------------------------------------------
            .def    RESET                   ; Export program entry-point to
                                            ; make it known to linker.
;-------------------------------------------------------------------------------
            .text                           ; Assemble into program memory.
            .retain                         ; Override ELF conditional linking
                                            ; and retain current section.
            .retainrefs                     ; And retain any sections that have
                                            ; references to current section.

;-------------------------------------------------------------------------------
RESET       mov.w   #__STACK_END,SP         ; Initialize stackpointer
StopWDT     mov.w   #WDTPW|WDTHOLD,&WDTCTL  ; Stop watchdog timer


;-------------------------------------------------------------------------------
; Main loop here
;-------------------------------------------------------------------------------

                                            

;-------------------------------------------------------------------------------
; Stack Pointer definition
;-------------------------------------------------------------------------------
            .global __STACK_END
            .sect   .stack
            
;-------------------------------------------------------------------------------
; Interrupt Vectors
;-------------------------------------------------------------------------------
            .sect   ".reset"                ; MSP430 RESET Vector
            .short  RESET
           

Setting the first Breakpoint on RESET works.

Setting the second Breakpoint on StopWDT fails

MSP430: Loading complete. There were 16 (code) and 30 (data) bytes written to FLASH/FRAM. The expected RAM usage is 0 (uninitialized data + stack) bytes.
MSP430: Trouble Setting Breakpoint with the Action "Remain Halted" at 0xf844: Address is past the end of memory

I tried Windows 8.1 and Windows 10 64Bit as Host.

Many Thanks

Akash

I believe that one needs to have a FET with the firmware from january or december and THEN start a debugging session letting CCS update the firmware as it does. As that seems to do different things if you are not getting these issues.
But here is some more information:

If i remove 'main' in the 'debug-configurations/settings/target/ auto_run_&_launch_options' settings and set some breakpoints elsewhere in the program whilst i am in edit mode (so at this stage they are s/w bps), it launches fine and executes to ONE of the bps....the other bps i noticed were now disabled. I also noticed that the bps have changed from s/w bps to h/w bps.

if i now try and re-enable another of the bps i get the message "MSP430: Trouble Setting Breakpoint with the Action "Remain Halted" at 0x4e74: Address is past the end of memory" EVEN THO THAT MEMORY location is below the bp that the program stopped at.

If i disable the bp that the program stopped at i can re-enable ONE other bp...EVEN THO a few secs earlier it gave that message about the location being beyond the endd of memory.

if i try and single step the program at this stage, my SD24 interrupt kicks in and i can single step in the interrupt function which is at 6BE8. At some point in that function the debugger suddenly decides that its had enough and presents this message..."MSP430: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0x6c4e: Address is past the end of memory"

if i then disable the bp that i had at around 4E74hm i can now set a new bp at 6C50h. ie at a location BEYOND where the message was.

So clearly the issue has nothing to do with memory and everything to do with the portion of the firmware dealing with breakpoints.

moshe

I'm having the same issues with the MSP-FET while debugging an MSP430FR5849. I tried using a debugger with an older firmware by selecting "ignore" on the firmware update prompt, but the problem still remains.

I also have to disable and enable the bp and reset the device in debugging, otherwise all breakpoints will simply be ignored.

This all happens with the most up-to date version of CCS on Windows.

For now I installed an older version of CCS v6.1. Once I let this CCS version "update" the MSP-FET everything is working again. Before the MSP-FET firmware downgrade,  stepping was also not possible, but the error message was simply "No single step" or something along that line.

Cheers,

Johannes

Sometimes you can not set the breakpoint where you want it 
due to Optimization high have rearranged the code so much with inlining and custom subroutines
that the line in C code no longer exists, so change to Optimization low and try again.

Good Morning,

The original problem "MSP430: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0xc53a: Address is past the end of memory" can temporally fixed by disabling the Software Breakpoints in CCS. Uncheck "Allow software breakpoints to be used". We are currently working on an update for this behavior.

The batch file for downgrading (V3V2) the MSP-FET430UIF will not work with the MSP-FET (Black color). The batch file (V2V3) is only legacy, CCS is doing the update from V2 to V3 of the driver. This file will be removed in newer versions.

Regards

Florian

Hi Tony

Thank you...that is quite an interesting point. I have never encountered such a situation but  i will certainly bear it in mind when other strange things happen.

But that is not the case in this instance.

moshe

I always have to turn software breakpoints off in IAR too (unless in simulation mode)
G2553 only have one breakpoint, but you can hopscotch with it.

Hi,

I was offline for a couple of days, here go my info:

CCS Version: 6.1.1.00022

Compiler Version: TI v4.4.3 (tried changing to TI v4.4.6 and the error still persists)

MSP430.dll version: 3.7.0.11

I have installed CCS on another computer and tried with one of the two MSP-FETs that were failing, it sent an updated firmware to the msp-fet and it worked correctly. Then I took that same msp-fet to the original computer where I was having the problems, and it said that the msp-fet needs an update.... strange, because I had updated it with the recently installed software just 5 minutes before. So it programmed a new firmware, and it is not working again.

Hi All

I have just set up ccs 6.1.0.00104 (as per help/about)...interestingly on installing it said ver 6.1.1.00015 & yes its the version currently available off the TI site....on a win10 installation running under vmware on a mac. That all works which is quite interesting in itself for those upgrading to win10.

i ported my projects (the EMETER project plus my own one) over to the win10 machine & yes it was a mission getting the projects to build due to all the different paths. 

I took my FET from the win7 machine & connected it to the win10 machine and started a debug session . CCS then said it needed to 'update' the FET which i let it do, and after that I continued on to debug without any issues whatsoever!!!...so this earlier version of CCS is just fine for debugging.

I then took that same FET with the 'upgraded' flash back to the win7 pc (which has ver 6.1.1.00022) and reconnected it and started a debug session. Sure enough CCS said it needed to 'upgrade' the FET, BUT, i clicked on 'ignore'. BUT, despite that i STILL got the error relating to the breakpoints....

Akash please note that 6.1.0.00104 (or 6.1.1.0015 i'm still confused about the numbering) does work fine as you found on March 2nd above...so it really does appear to be something in the 6.1.1.00022 release that is the problem.

AND:

1. is there any way to downgrade the CCS from 6.1.1.00022 to the 'upgrade' before that one?

2. why did the installation i did on win10 initially indicate 6.1.1.00015 but in help/about it shows 6.1.0.00104? 

cheers

moshe

Hi Mike

Thanks for the advice - yes, the DLLs were different by one minor rev (two days). Updating the older one works (debugger still functions correctly in CCS)

cheers

Trevor

Hi Mike

I think you have just nailed the problem!!

i looked at the msp430.dll on my win10 installation (ver 3.4.3.4 of 2/5/15) vs the msp430.dll on the win7 installation (ver 3.7.011 of 17/2/16).
i copied the dll from the win10 installation to the win7 installation and launched ccs on the win7 machine....
1. there was an update indicated...i had a peek to see what it wanted to update...sure enough it was msp430.dll so i cancelled that update.
2. i then started a debug session.....wow....absolutely NO issues whatsoever.

So it appears the problem is in the latest msp430.dll of last week (or when this issue started)...so how can i locate the version of the msp430.dll
just before the last update?

[update....my mistake, the update that ccs wants to do is for the msp432 emulators...i have just done that and it did not affect the msp430.dll so it remained the one i copied from my win10 installation and thus i can still debug without issues...]
moshe

Hi Florian

Thanks for that...as of 10:10 GMT 16/03 my CCS reports that there are no updates...perhaps they haven't filtered thru yet.
Presumably those updates will also bring my CCS up to 6.1.2??

Yes, i am aware for the dangers of transporting dll's across versions...as they say, "desperate times call for desperate measures"....fortunately in this case it was ok. 

cheers

Moshe

Florian,

I'm still not seeing an available update to the MSP430 Emulators in my CCS Installation Details.

Do you know when this will go live? Is it already supposed to be live? 

Below is a screenshot showing my current version, and the failure to find an update.

HI Moshe,

Have you checked for updates in CCS6.1.2? The is an update for the MSP430 Emulators v6.3.1.10 This fixes the breakpoint issues.

By the way the MSP430.dll always includes an firmware image of the MSP-FET. When CCS starts it checks if MSP430.dll and the firmware on the MSP-FET are in sync. If not an updates is requested. Due to this fact it can sync. with the MSP-FET.

I have also attached a picture of my tested and working CCS version.

Thanks & Regards

Florian

My MSP430 Emulators Version is 6.3.1.8.

Search for Updates says "No Updates Found".

How can i get the Update?

Thanks

I can confirm what Florian said is valid.

I "bit the bullet" so to speak and did a fresh install of CCS 6.1.2 and was able to update to the new package (v6.3.1.10).

I can now set multiple SW breakpoints and run to them with no problems at all.

Have you checked for updates in CCS6.1.2? The is an update for the MSP430 Emulators v6.3.1.10 This fixes the breakpoint issues.

As others such as TylerWitt  has shown our CCS6.1.2 shows version 6.3.1.8 for MSP430 Emulators and says no updates are available. Please, how do we get this update???? Where do we download it????

Respectfully,

Jeff Rockel

Hi Pedro,

Just to let you (and others) know I had the same problem.

I also got the trouble setting breakpoint Address is past the end of memory error.

It seems that when you change your source code in CCS and rebuilt and had breakpoints already set this error sometimes occurs. I'm using the newest MSP-FET emulator/programmer tool.

When I have this error I can get around it by removing all breakpoints (right click in the breakpoint window and select 'remove all'). Then rebuild if not done already and set new breakpoints. Now if I start debugging the error does not occur anymore (until I change the source code again).

This error does however not always occur when you change your source code.

Please let us know if this workaround also works for you. Needless to say that I still regard this as a bug.

BTW: I am using the latest version of MSP430 Emulators dll (6.3.1.8)

Hello Florian,

it works.

Many Thanks,

Andreas