MSP430F2618 Large Memory Model Breakpoint Problems

There's another thread bout this.
It's a known problem.
There have been some proposals for workarounds, but on the bottom line it needs to be fixed in the debugger. Not the only one I fear.

Eli Hughes said:

This is a project killer!

Not really. I did all my MSP projects (and there were many) without ever launching a debugger. It's a nice thing to have one, but if you absolutely cannot go without one for MSP programming, then you should look for a different field of operation. :)

I agree with Eli.

I don't know if not using a debugger at all is always good, but good software is key in any embedded application. Good software is also hard to write since most people
"hack" it to work without considering everything and avoiding the jump to a debugger everytime there is a problem will let you think about it.

A simple workaround is to break your program into small pieces and ensure each piece works well by properly designing it and testing it.

If you have a UART connection to a PC, you can debug similar to using printf by sending the data out in strings.

 

GL

None of us here knows what your application is and whether it requires this or other certification. Our suggestions were
simply suggestions and possible temporary solutions, and hopefully the bug will be solved so that everyone can get the most out of the MSP430.

GL

Gustavo:

I do appreciate all the help.  Sorry for the mini-rant but I have strong opinions about tools I use...... 

I was hoping that this all would have been a misunderstanding on my part of some debugger setting.   It is also surprising that this issue has been outstanding this long after the release of MSPx devices.     In the end this issue was my fault for selecting the wrong part/architecture for a project as I knew in advance I would need the extra code space. I have used the 1611 device on 6 products with a good deal of success and had high expectations for the  2618.   I usually don't use parts with new architectures (escpecially ones with banked/stovepiped extensions) but thought it might different because of the high quality of the previous generation.  Mr. Murphy has proven me wrong again.....

Hopefully this gets resolved soon!  I just saw some post on another forum with the same issue from 15 months ago.....

 

Eli,

If your only need for addresses above 0x0FFFF is for extra code space, you could just keep using the small memory model.  We do just that on projects using the '5438(A), '5419(A), and '5529.  The small memory model lets your code extend into the complete 20-bit address space.

The final code is actually much more efficient this way too.

Jeff

Not a problem :D, We all have strong opinions.

I have used the MSP430F1611as well in several applications and as someone else said, it's a workhorse. It had very good support. Unfortunately, it lacks what are
now common features in other MSP430s.

I didn't realize it's been 15 months for this issue. Sometimes it's hard to know what issues will pop out at the design stage.

Good Luck with Mr. Murphy, he's always going around making our life interesting.

GL

 

Eli Hughes said:

It's a project killer as I cannot trust anything related to the FET tool now with a rigorous test.

If the project depends on the existence of a debugger, well...

Eli Hughes said:

Not being able to handle addresses greater than 64k is a big deal.

I totally agree that this is a bug that makes the TOOL somewhat unreliable, but this doesn't mean that it makes a project impossible.
I've seen many occasions where people were unable to solve a problem despite the fact that the debugger was working 100% correct. While I did many projects myself where I never used a debugger. Well, I did quite a few projects before the term "debugger" was even known (and many others did too).

Eli Hughes said:

I am pretty sure I don't need another field of operation!

You did notice the smiley, did you?

Eli Hughes said:

Programming embedded systems that have multiple CPUs, gate arrays, etc without the proper tools is a waste of time (and money).

Unless the debugger is capable of stopping all CPUs and the external circuitry all together, it isn't the 'proper' tool. IMHO, the use of a debugger is just 'poking around'. Everything 'realtime' cannot be debugged by a debugger. A well-placed information output (sometimes a ssimple as a blinking diode) is often a better debugging tool than a debugger.

Eli Hughes said:

For hobby project, it might suffice but one needs to fundamentally trust their tools.

For a hobby project, you shouldn't need a debugger. But anyway, at first you should trust your brain. It's not a debugger which produces bugs (at least normally).

Eli Hughes said:

Just because something compiles and loads doesn't mean it "works". 

Surely not. It only means that there were no syntactical errors. If the compiler could analythe the logic behind a program, we wouldn't need a programmer anymore, just tell the compiler what you want. Anyway, todays compilers are smart enough to detect what you might mean. And sometimes this leads to different code than you wanted (dead code elimination, loop unrolling etc.)

Eli Hughes said:

All the code I write has to pass rigorous safety certification.

And a debugger does the certification? Hmm, I'd say this isn't the right choice.

Eli Hughes said:

I have to prove that the code followings a determinitistic state machine to pass.

No doubt. But what has a debugger and its ability to place breakpoints above 0x10000 to do with this state machine? If the code only runs flawlessly when the debugger is attached, then something is buggy.

Eli Hughes said:

Testing that with a UART is primitve. 

That's just your opinion. It's less intrusive and more real-time compatible than settign breakpoitns with a debugger.

Eli Hughes said:

There are large class of problems you will simply never catch without a hardware based debugger. 

I doubt it, but there are definitely a large number of problems you won't be able to catch WITH a debugger. Unless you simulate the whole environment ( including the operator).

A debugger is a tool. It is not a prerequisite for programming (okay, if you have to rely on foreign code libraries, such as Microsofts .NET environment, the debugger IS a prerequisite for any project).

I didn't plan to be so detailed about this topic. But your reaction forced me to.

I wonder where humanity would be if Adam had cried for a debugger before talking to Eve.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

HI Elisha Hughes,

 

This issue has been solved in the CSS version 4.2.1. Could you please update your CSS and check if you see your issue with the new version, too.

 

If you see it also with the new version, please contact me to get it fixed.

 

Thanks & Regards

Florian