Bugs (4) with Breakpoints in Code Composer

At least for the first problem there is a fairly simple solution: don't put any code into the lower 64k.
Put all your constants, variable initializers and such there, but not any code. You can even mode the ISRs to the area ybove 64k by forwarding (there must be a stub code in the lower 64k, but this needs to be only a single jump instruction)

Surely a fix in CCE would be better (did you try CCS? The E in CCE stands for 'Essential'), but until a fix is out and if you really need the debugger (I never used one for MSP development, really), it is an option.

Sorry, I don't follow your solution for item 1.  Are you saying that if you put all your code in 1 x 64k segment it will work?
The application is currently up to 125k, and will soon be > 128k - with 29 cpp files, > 40k lines of code, and easily > 40 state machines.

How do you develop without the debugger?  At first glance, I don't see how that is a practical option.

We tried CCS v4 and it had the same problems. Many more to post yet.  Looks like CCS v4 is CCE v3 with a new front end and same back end.

PeterO said:

The application is currently up to 125k, and will soon be > 128k

Anyway, the problem seems to be the usage of the EEM. On some devices, the EEM supports only 8 or 16 bit mask on the address bus, on teh 54xx devices, 2 20 bit breakpoints cna be set, but only if the debugger supports it. It seems that only a 16 bit mask is set in your case, which leads to a break in every 64k bank.

Another ide comes in mind: you can use a breakpoint variable. Create a global, volatile variable, and set a breakpoint on change. Whereever you need abreakpoint, you just write to this variable and the debugger will break. This allows an unlimited number of 'breakpoints' but requires these to be set at compile-time.

PeterO said:

How do you develop without the debugger?

Workarounds.  Workarounds.  And for anyone writing a serious (size) application they are no good.  Now we wait, as I have been for months now on item 1, for TI to fix the problems. TI, help please...
(Yes, not a happy camper.)

PeterO said:

Workarounds.  Workarounds.  And for anyone writing a serious (size) application they are no good. 

Well, what size a seriuos application needs to have seems to be a relative thing. Our energy meter takes only 8k code and only 256 bytes ram. Which is the limit of the MSP1232. Working perfectly and done without ever thinking of a debugger. Not even a serial connection. Just two LEDs and an RF modulator.

Those processors with more than 64k address range are fairly new. And I often found that when someone told me that he needs more flash, he rather needed more imagination when writing code. :)

Also, large programs are just a collection of small programs. If you properly design the small ones, the large one will work too. That's my experience. A debugger is only needed if you work in a non-deterministic environment such as Windows or if you prefer to design your programs by try-and-error.
I must admit that a debugger is a nice thing, but if you NEED one, then something is wrong - either with the environment of your code (and there is none on the MSP) or with the way the code has been written.

But well, I'm member of a generation where 640k conventional memory was unbelieveably much and nobody could imagine ever needing that much, even for games. Today, a simple calculator program is by magnitudes larger (yet does not provide more functionality). And often much buggier, despite of the existence of powerful debuggers.

Nevertheless, you're right, this printf mess should be addressed and documented ASAP.

We seem to have drifted off topic here...

This post is about 4 problems with code composer - priorities 1 high, 2 medium and 1 low.  Anyone who had to work with these problems on a daily basis I'm sure would be frustrated too.

We have decided we want to use a debugger.  We bought the development environment, debug JTAG hardware and micros from TI.  So as a customer it reasonable to expect the product(s) we have purchased to work properly.  As a complex software product I don't expect it to be perfect, however, working with technical support to fix the issues is a reasonable request.  Keep emailing TI support, no reply.
(trying to stick to the facts)

If you have the same problem(s) please add a post here.  Refer to item 1, 2, 3 or 4.

TI, please look into these 4 items....

Hi PeterO,

"3.  Ditto above, with Reset instead of Reload.
Depending on the code sometimes this occurs all the time.  Otherwise it occurs sometimes."

I'm using IAR Embedded Workbench and MSP430F5418 and I'm facing exactly the same frustrating problem. As a workaround I found out that after reset if u remove the breakpoints and insert them back and then run the code it hits the breakpoints. U need to repeat this procedure after each reset. Rather annoying ain't it? It worked with me.

Does TI hear us?

Hi Peter,

Do you know which version of CCSv4 you tried? (I'm looking for the full version number (Help->About Code Composer Studio) which looks like 4.x.x.xxxxx)

Thanks

ki

Hi,

On this page, it was version 4.1.2, dvd image.  Cant look at help / about.  It's not installed on my PC anymore.
http://processors.wiki.ti.com/index.php/Download_CCS

I see there now version 4.1.3.  A quick read of the release note shows these 4 items still need some TLC.

Peter

Ki,

Whats TI's status with these items?  Items 1, 2 and 3, particularly item 1, is causing me grief and making my job difficult - on a daily basis.  If I can help please let me know.

Peter

Peter,

Could you please try CCSv4.1.3? We're made a number of changes, which may resolve some of the issues that you are seeing. Please let us know if you see any improvements.

I'll make the software component owner aware of the issues you reported so we can do further anaysis.

Regards,

Markus

Markus,  Just acknowledging your message.  Thank you for the suggestion.  Been put onto another urgent job for a while.  Will be a few weeks before I can reply. Sorry, it's out of my control.

TI,

Using Code Composer Studio , Version: 4.1.3.00038.  Same problems with breakpoints in version 4 - see items 1 to 3 in the 1st message. Set breakpoint at address 0x0xxxx.  Code composer stops at 0x1xxxx.  As the application gets larger there also extra breakpoints at 0x2xxxx and 0x3xxxx.  See attached showing item 1.  Hope you can look into it soon.  This causes me grief on a daily basis.

Peter

TI, please reply.  Regards, Peter

Paging TI.  Come in TI...

Help please with these items - see numbered items in initial post on this thread.  Been trying to get these breakpoints items fixed for months - in this forum since July (2 months ago)  and have been emailing support@ti.com and tiasia@ti.com since February (7 months ago).

Can you please provide a fix or workarounds?

2 weeks later...

TI, helloooooo anyone there?

Hi Peter,

Sorry for the delay. I will move this to the CCS forum for better visibility by the CCS team.

I am trying to reproduce the issues using CCS 4.1.3 with a 5438. I cannot see any of the four issues you describe. CCS seems to work as expected. Providing a reproducible test case would go a long way in helping us resolve the issue

ki

Peter,

I can reproduce the first issue using the attached project. Since it involves setting up a HW breakpoint we are still unsure if this is an issue with the silicon (I hope not!), the low-level device driver or the high-level IDE. We'll keep you posted on what is the outcome of these discussions.

I didn't have luck in reproducing 2, 3 and 4 here. I am using CCSv4.1.3.00038 on Win7/64bits. I will keep trying to "break' my setup.

Regards,

Rafael

Hi.

If your using the program in the attached F5438_test.zip to reproduce these issues you'll never find them.  With a small program on a MSP430F5438 you'll never reproduce these issues.  I never have seen any of these issues with small programs and didn't come across these issues until my program became larger (using more than 1 bank of flash memory).  I and other engineers here write small applications (all code in Bank 0) for MSP430 and they don't have these issues.

As per document TI SLAS612C page 14, the MSP430F5438 datasheet, flash memory is organised as follows:
Bank 0 045BFFh–040000h, 00FFFFh–005C00h
Bank 1 01FFFFh–010000h
Bank 2 02FFFFh–020000h
Bank 3 03FFFFh–030000h

If your program is small, say 1k it will sit in all in Flash Bank 0 from 0x005C00h upwards.  All is well with all the code in 1 bank.

When your application uses 120k of flash, like my current application, Bank 0 and Bank 1 are full, the rest of the program will reside is a part full Bank 2.
When you set a breakpoint at address, 0x05C00, you'll also get bonus unwanted breakpoints at 0x15C00 and 0x25C00.  This is issues number 1.

If you still need an example program to reproduce the issue I can do so.  It's not a 5 minute job as I'll need to put something together so I'm checking first.

Regards,
Peter

Peter,

Although the code is small, I placed the functions processing_fxn() and processing_fxn2() in the memory sections .far_code and .far_code2, by using  the #pragma CODE_SECTION.

msp430x54x_adc12_01.c said:

#pragma CODE_SECTION(processing_fxn, ".far_code")
int processing_fxn(int input)
(...)

#pragma CODE_SECTION(processing_fxn2, ".far_code2")
int processing_fxn2(int input)
(...)

If you look at the linker command file, these sections are respectively located at addresses 0x20000 (memory segment FLASH3) and 0x30000 (memory segment FLASH4), thus allowing to reproduce the "mirrored breakpoint" effect.

lnk_msp430f5438.cmd said:

MEMORY
{
(...)

    FLASH                   : origin = 0x5C00, length = 0xA380
    FLASH2                  : origin = 0x10000,length = 0x10000
    FLASH3                  : origin = 0x20000,length = 0x10000
    FLASH4                  : origin = 0x30000,length = 0x05C00

(...)
}

I haven't yet heard from the internal team, but please let me know if you have any additional questions.

Regards,

Rafael

Sorry, I see from your reply that you appreciate the issue.  What's the 'internal team' and their interest in this item?

What else can I do to help get these items fixed?

Peter

Peter,

Please see the attached file; it contains a modification to the emulator configuration that allows the breakpoints to be properly set in all the memory segments. I tested it with my test case here and it worked, but I strongly suggest you checking in your code.

The details follow in a readme file supplied in the .ZIP file. Just for reference I reproduce its contents at the end of this post.

Please let me know if this allows you to move on with your project debugging.

Best regards,

Rafael

msp430_emu_readme.txt said:

=============================================================================
========================= MSP430_EMU_README.TXT =============================
=============================================================================

This file is a workaround for an issue that causes breakpoints to be mirrored
in all FLASH memory pages of MSP430 devices that have extended memory.

Additional details can be found at the forum thread below:
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/55744/245595.aspx

FILES INCLUDED WITH THIS WORKAROUND:

- <msp430_emu.drv> - the emulator interface file that contains the workaround
- <msp430_emu_readme.txt> - this file!

IMPORTANT NOTES:

- This file is provided as-is without any support.

- This file is a workaround to a bug on the MSP430 emulator DLL file,
  therefore is not a permanent fix to this issue.
 
- Any changes to the Mask property in the Breakpoint manager cause this
  workaround to lose its function.
 
- It is designed to work ONLY with CCSv4.1.3.00038.

- Unless otherwise noted, this workaround must be removed if Code Composer
  Studio is updated.
 

INSTALLATION:

- Close CCSv4;

- Open the directory below in Windows Explorer:
  <CCS_INSTALLATION_DIR>\ccsv4\DebugServer\drivers

- Rename the existing file <msp430_emu.dvr> to <msp430_emu.dvr.old>;
 
- Extract the contents of this zip file to the same directory above.

- Start CCSv4.  

Peter,

A bug was filed today under the number SDSCM00038216. Please check its status at the link SDOWP in my signature below.

Regards,

Rafael

Peter,

I received an updated DLL that also fixes the problem (tested only in F5438 devices) - I can send it to you in private, but you will need to uninstall the hack I sent before.

The fully tested DLL will be released in November.

Best regards,

Rafael

Great. Please send the update. If you click on my name in the forum that should show you my email address.

Peter,

I just sent it.

Regards,

Rafael

Just installed Code Composer Studio version 4.2.0. Installed it in a new directory and created a new project so it's independent of version 4.1.3.

Having this problem again with additional breakpoints.  From earlier posts/emails, I was expecting this item was going to be fixed in version 4.2.0.  As a workaround is it ok to install the version 4.1.3 patch on version 4.2.0?

Also having a new problem with version 4.2.0.  The debugger stops at the breakpoint but the MSP430 resets and starts running again.  I can see this because my diagnostics, out a MSP430 serial port, say the program is restarting and going through the startup sequence.

Peter,

The patch was tested with 4.1.3, but feel free to try using it in 4.2.0. I didn't have time yet to test it here, since I was told the final package that contains this fix wil be shipped with CCSv4.2.1.

I will also try to reproduce the issue you are seeing in 4.2.0. Can you hit this with the example project I sent?

Cheers,

Rafael

Peter,

I couldn't reproduce this in my copy of CCSv4.2.0.10018 with the example project.

Regards,

Rafael

In the patch readme file it said for use with 4.1.3 only.  So was waiting for your ok before using it with version 4.2.0.

Thank you.  Putting the breakpoint patch on version 4.2.0 fixes the reported problems - see my post 11-09-2010 9:53 AM

---------------------------------
Part 2:
This leaves item 3 in the 1st message of this thread outstanding.  In brief this is:
- debug the program, stop at a breakpoint, reset the processor.
- run the program again.  Break points are listed in the Breakpoints tab.  The debugger does not stop at these breakpoints.

The workaround is to reset the processor, delete all the breakpoints, add all the breakpoints, and run the program again.
With the breakpoints at various locations across multiple files this is a pain.  It wont take too many days before I start moaning and complaining about it.
I hope you can help.