MSP430F67791: Code composer output issue

Hi Nayani,

The reset vector is used to trigger a system level reset and do some operations, for eample clear the data in RAM, and then jump to the main code.

The main code is stored in the main flash area, and it might be in @C000, or other address optimized by the complier.

Below it the memory table of the device:

B.R.

Sal

Hi Sal Ye,

Thanks for the reply. The issue is not about reset code but the vector itself. I have pasted below the output from IAR (.txt file)

@C000
20 20 20 20 20 20 20 20 43 4C 4F 53 45 20 54 48 -- CLOSE THE PROBE
45 20 50 52 4F 42 45 20 20 20 20 20 20 20 00 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 00 20 20
20 20 20 20 20 20 20 57 45 54 54 49 4E 47 20 43 -- WETTING CYCLE
59 43 4C 45 20 20 20 20 20 20 20 20 00 20 20 20
20 54 69 6D 65 20 4C 65 66 74 20 3A 20 20 20 20 -- Time Left :
20 20 20 20 20 20 20 20 20 20 20 00 20 20 20 20
20 20 20 20 50 4C 45 41 53 45 20 57 41 49 54 2E -- PLEASE WAIT...
2E 2E 20 20 20 20 20 20 20 20 00 20 20 20 20 20
20 20 20 20 20 20 20 44 4F 4E 45 21 20 20 20 20 -- DONE!

and from CCS (intel Hex file) 

:02FFF8000CC13A
:02FFFA000CC138
:02FFFC000CC136
:02FFFE00F0C051      // as per document this is the reset vector address and the vector is 0xF0C0 (please correct me if I am wrong). There is no record in the hex file containing this address (not necessarily record starting with this address but I looked for any record which encompasses this address). 

The crux of the issue is, CCS output when loaded into FLASH it is not working. 

Please help solve this problem. Than you.

Best regards

The contents of the Reset vector (at 0xFFFE) would be 0xC0F0, which would seem to be within your .text section. I expect this appears as something like "_c_int00_<mumble>" in your Debug/<project>.map file.

As to the malfunction(s) you're observing, I'd start with the Warnings -- they may be telling you about IAR features that CCS doesn't support.

Hi Bruce,

Thanks for the post. I have checked .map file. Will check again to confirm. As for the warnings, they are mostly related to subscript out of range, power consumption related to I/O ports etc and not conversion. I will update after going through the map file.

The power consumption messages come from the ULP Advisor, and they are "Advice" rather than "Warnings" -- they can be ignored without guilt. If they produce too much clutter, you can turn them off at "Project->Properties->Build->Compiler->ULP Advisor" (button "None").

The "subscript out of range" Warning (at least on the face of it) seems worthy of attention.

Hi Bruce,

Thanks for showing how to suppress warnings. Yes, the subscript requires attention as it may cause catastrophes. At this point of time my attention is to see that the code gets executed, though I increased the array sizes and not getting those warnings. Please see my post above and advice. Regards

I'm not sure which (unanswered) questions you're referring to. As Sal said, there's no reason to assume that the IAR and CCS compilers (linkers) will lay out memory the same. In particular, with CCS I wouldn't expect constant strings (section ".const") to appear at the bottom of Flash since (at least) the ISR/Reset code would come first. (I don't remember how IAR lays things out.)

If you've remedied all the warnings, I imagine the next step would be to debug the problem. What is it that doesn't work? What happens when you run it?

Document SLAU157AS Chapter 7 mentions some IAR->CCS migration things to watch for:

https://www.ti.com/lit/ug/slau157as/slau157as.pdf

Hi Bruce,

I am not comparing memory layouts. The code compiled in CCS just does not work. That's the problem. The simplest is initialization of LCD and displaying a welcome banner. This does not happen. Regards.

Thank you. I shall go through. 

Hi Nayani,

I have a suggestion that you could select TI-TXT HEX format rather than intel-HEX and check whether it work.

B.R.

Sal