CCSv4 & MSP430F54xx family: Upper flash memory bank (bank 2) access problem

Hi,

have a look at this post http://e2e.ti.com/forums/t/9296.aspx. Be shure to enable the --large_memory model.

Rgds
aBUGSworstnightmare 

BUGS,

I appreciate the response.  However, I believe I have enabled all the documented gotchas for dealing with large code and large data under MSP430X.  I've enabled --large_memory_model and am using the rts430xl.lib for the msp430f5419 target.  The post you refer to appears to concern itself w/accessing the 0x10000 address range (bank 1) on the 5438.  I have no problem accessing bank 1 on the 5419 - it's bank 2 (0x20000+ addresses) that's the issue.  I'm waiting to see if this isn't an inherent problem with the msp430f54xx support files under version 4.0.1 of CCS - apparently a v. 4.0.2 release for CCS is coming out 'any day now'.

regards.

gifford scott

DST

Still looking for fix to this issue... New release of CCS (v4.0.2) has same issue of not recognizing flash bank 2 on the msp430f5419.

Hi Gifford,

I am looking into this issue, but I haven't been able to reproduce this error. I tried loading code to 0x20000 on a MSP430F5438, and did not get the verification error that you are experiencing; can you determine if the issue you are seeing isolated on the F5419 device?

Note that I have suggested a solution to the error on reading memory above 0xFFFF on F54XX devices in another post, although it is unclear if this issue is related to the one you described above.

http://e2e.ti.com/forums/p/12032/47140.aspx#47140

If you are still experience this issue after trying the fix, can you provide additional detail for further analysis. For example, provide an example project that you are seeing the issue on, as well as the full command linker file you were using; and definitely comment on if this is an isolated issue on F5419 devices.

Let me know if you have any questions. I look forward to hear back from you.

Ricky.

Ricky,

Still looking for fix to this issue...

Wrt to further detail, I can provide again what I provided on the other post (http://community.ti.com/forums/t/12032.aspx):

1) Load the 'msp430x5xx C Example' project into CCS V4.0 using the MSP430F5438 Experimenter Board with the '5438 replaced by the '5419.  If you run the project as is, the project will load, but you will see memory access errs in both the [0x10000 ... 0x1FFFF] (flash bank 1) and the [0x20000 ... 0x25BFF] (flash bank 2) memory range.  Loading your fix, mspx_fix.gel, resolves the memory window errs, but does not fix the disassembler window errs in the very top part of the flash bank 2 range, ~0x25BA0 and above.

2) Modify the loaded 'msp430x5xx C Example' project under CCS V4.0, by editing the linker command file, lnk_msp430f5419.cmd:

- Change the following lines in the MEMORY section:

FLASH    : origin = 0x5C00, length = 0xA380

FLASH2    : origin = 0x10000, length = 0x15C00

replace with:

FLASH0    : origin = 0x5C00, length = 0xA380

FLASH1    : origin = 0x10000, length = 0x10000

FLASH2    : origin = 0x20000, length = 0x05C00

- Change the following line in the SECTIONS section:

.text           : {} >> FLASH                   /* CODE                                        */

replace with:

.text           : {}  > FLASH2                   /* CODE                                        */

All other code sections go into FLASH0.

Let me know whether you have further questions.  As mentioned in my other post, I do not have '5438 devices on hand, but *please* tell me that you intend to test CCS V4.0 against the MSP430F5419, at some point!

regards,

gifford scott

DST

Gifford,

Thank you for your detailed information on the problem you are having. We have isolated a couple of the problems here.

1. Memory View.

It is nice to hear that the temporary fix is working for you. I am currently implementing the actual fix right now, and will be available in the next release (we are still determining the best way to roll out the fix).

2. Disassembly View.

This issue has been tracked down, and will be fix very soon. The fix will be available at the same time as the first issue.

3. Program Load for MSP430F5438.

Unfortunately, we do not have the specific board you are using in our Office at this time. But I would like to inform you that we have asked the MSP430 team to help us look into this.  We will continue to look into this issue and will update you when we have any progress on this.

Let me know if you have any questions. Thanks again.

Ricky

Gifford,

Another quick update.

The Memory View and Disassembly View issues you reported has been addressed, and will be available starting in the next CCS release.

Both of these issues were visibility issues in the GUI, and should not prevent you from loading programs onto the board.

Regarding the program load issue at address 0x20000, I just heard back from the MSP430 team and after testing it on the F5419, they were not able to reproduce the issue you are seeing. Here is a short description on the testing process:

1. Used the F5419 on a standard FET board. Everything worked just fine
2. I used the experimenter’s board, just like the customer. When I had the Power switch set to “FET” I could not connect to the device at all (No MSP430 found). However, when I was changing the power switch to “BATT” everything worked without any problems.

Based on their testing, there are two possibilities I can think of.

1. The test was done on a different emulator/version that yours.

- Can you tell me which emulator you are using for connection? (Parallel or USB)

- I think you mentioned you tried it on both CCS4.0.1 and CCS4.0.2. Is this correct? and were you getting the same verification error on both versions?

2. The is a problem with the board you are using.

- Do you happen to have another F5419 board available for testing?

- you mentioned that program load works on the original command linker file. In that case, can you try using the original command linker file to load your program, but fill the FLASH2 section with something like 0xABCD, and see if you get a verification error. You can also check the data at address 0x20000 in the memory view after the program load to determine if the program load was successful at that address.

For example: FLASH2: origin = 0x10000, length = 0x15C00, f=0xABCD // fill unused memory with 0xABCD

Please also note that I will be getting a F5419 board in our office next week, so that I can continue to work with you to resolve this issue.

Let me know if you have any additional questions.

Thank you very much.

Ricky

Ricky,

Thank you very much for your efforts on this issue.  I apologize for allowing my frustration on this particular issue to show on my last posting.  Unfortunately, I could not think of a better way to draw attention to this issue.  Before I discuss your fix, could you please provide some more detail as to the actual device-specific bug?  I'd like to know the following details:

1) Is this related to the JTAG errata w/the '5419?

2) After attempting to erase/write [0x20000 ... 0x25BFF], the JTAG interface will frequently hang - requiring the power-cycling of *both* the '5419 part and the USB FET interface.  Can you identify the issue here, and perhaps a work-around?

3) I do not have access to the '5419A part yet, but the local TI FAE will be coming to our site to discuss the '5419 & '5419A today (about 1:30 am, Bangalore(?) time).  Can you confirm whether the '5419A will have this same defect?

Again, thanks for providing your fix.  For now, I have been using a work-around, in which I only attempt to program the flash bank 0 [0x05C00 ... 0x0FFFF] & bank 1 [0x10000 ... 0x1FFFF] via the USB FET, and allow the target code to self-program flash bank 2 [0x20000 ... 0x25BFF].  With regards to your fix, I have a couple questions:

4) Do I need to reset the USB FET or CCS application when changing GEL files?

5) When is the release date for the next CCS release that incorporates fixes for this issue?

It still surprises me that you have not received more feedback on this particular issue, but, believe me, I am relieved that this defect has now been reproduced and confirmed by your development team.  Thank you again for your efforts.

regards,

gifford scott

Gifford,

I am trying to get some answers for your questions from the MSP team, but I have not heard back from them at this point.

As for the questions on the fix.

4. You do not need to reset the USB FET or CCS when switching the GEL file. GEL files are related to the Target Configuration (.ccxml) file and therefore you can switch GEL files before launching the debugger or debugging active project.

You can check which GEL file you are using for the current debug session by going to Tools->GEL Files in the Debug View.

5. I don't know the official release date of the next release, since I am not responsible for the scheduling of releases; but I understand it should be release within a couple of months. I will try to find something more official for you if possible.

I will update you on answers to Q1-3 as soon as I hear back from the MSP team. Let me know if you have any questions.

Thanks.

Ricky

Ricky,

I've confirmed that your mspx_fix_F5419.zip file does appear to fix the issue for MSP430F5419.  Thanks very much for your support.

regards,

gifford scott

DST