• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 413 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28335: hex instructions meaning

Paloma de la Fuente Vega
Intellectual 650 points
Part Number: TMS320F28335
Other Parts Discussed in Thread: UNIFLASH

Hello, 

I have a random issue that seems to depend on how we program flash memory. We program, in any case, from sector G to B. But sometimes, when we program flash with our custom applications, we get a different behavior than the one we get when it is programmed with Jtag and CCS. 

I have exported the memory from a board that fails and from a board that doesn’t and compare it too with CCS disassembly view. I see that flash are different in one small zone. Those addresses are always at the begging of Sector G (0x308000).

I see differences in TRAP instructions (check in disassembly), that I guess that won’t change the app behavior, but I don’t understand why they are different. For example in one board I see 0035 and in the other 0030. Do you know the reason?

And I see differences in instructions too like these:

One board:

004D0061                                        

00790020

The other board:

00530065

00700020

As I can see in the disassembly, I know that the first board instructions mean the following:

004D0061    LB           0x0d0061

00790020    LB           0x390020

Could you tell me the meaning of the other board instructions?

Any idea why this can happend. 

Regards,

Paloma

  • 0
    TI__Guru* 81560 points

    Paloma,

    I want to make sure we are looking at the correct decode, when you listed the contents of the memory above is this directly from the memory browser viewing as 32-bit data, or as 2 16-bit values that you concatenated together?  

    While the decode for 004D0061 is LB 0x0D0061 as you have shown, address 0x0D0061 is not a valid memory address on this device.  L7 SRAM ends at 0xFFFF and XINTF6 (external SRAM) begins at 0x100000.

    If you could just save the memory(or screenshot it if that is simpler) at some locations that are different I can make sure of the decode.

    In terms of why there is a difference, it sounds like this is un-expected, perhaps it is some issue with how the output file from CCS(.out) is being made into a hex file for loading with your custom application?  If you could give some more details on the steps you take to create the file that your application loads

    In the memory save you have done in the respective loadings, do you see same contents in different places or just different memory contents period?

    If you want to attach a copy of your .CMD file I can see if anything jumps out to me as special on how sector G is being used.   

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Intellectual 650 points

    Hello Matthew, 

    Thank you for your response. I hope we can find where is the problem.

    The content listed without assembly meaning has been exported with Uniflash memory browser in hex format. The other content with assembly meaning  is gotten from the disassembly view:

    I see only the following diference in the exported memories (exported from different boards with Uniflash hex format):

    Board with the expected memory:

    :2080000055AA0071574FFFFFDD44FFFF004D006100790020003100300020003200300032D1

    :208010000034002000610074002000310031003A00350031003A003200370000761F039B2F

    Board with the unexpected memory:

    :2080000055AA0071574FFFFFDD44FFFF0053006500700020003100330020003200300032CD

    :208010000033002000610074002000310034003A00350030003A003500380000761F039B2A

    Out custom app downloads bytes of memory that are gotten from hex file created by the CCS C2000 hex utility appling extended tektronik format.

    Looking at the cmd, there is something I don’t understand. The expected exported memory matches with its dissasembly view:

     

    Those address in CMD are defined as following:

    PRG_STATUS     : origin = 0x308000, length = 0x000001

    BEGIN                                   : origin = 0x308001, length = 0x000002                 /* User Program entry point */

    TARGET_PREV : origin = 0x308003, length = 0x000001                

    TARGET_ID                         : origin = 0x308004, length = 0x000001                

    COMPILE_DATE_PREV : origin = 0x308005, length = 0x000001

    COMPILE_DATE : origin = 0x308006, length = 0x00001

    FLASH                                   : origin = 0x30801E, length = 0x02FFE2                  /* On-chip FLASH [0x308000 SectorG hasta 0x338000 sectorB inclusive]*/  

    PRG_STATUS is hardcoded to 0x55AA, is is possible that program entry point code_start is steepping on CMD regions listed before?

    Thank you,

    Paloma

  • 0 in reply to Paloma de la Fuente Vega
    TI__Genius 16371 points

    Hi Paloma, Matthew is out of the office, hopefully he will be able to respond later this week.

  • 0 in reply to Joe Prushing
    TI__Genius 16371 points

    Hi Paloma, I just wanted to update you, Matthew wont be back until Tuesday, I apologize for the delay.

  • 0 in reply to Joe Prushing
    TI__Guru* 81560 points

    Paloma,

    Apologies for the long time in replying.  I understand the memory contents now, these are not instructions but just data storage.  Looking at the dis-assembly for these isn't necessary, as code should not execute here(rather just be read).

    However, in your .cmd file I think I see the issue:

    PRG_STATUS     : origin = 0x308000, length = 0x000001

    BEGIN                                   : origin = 0x308001, length = 0x000002                 /* User Program entry point */

    TARGET_PREV : origin = 0x308003, length = 0x000001                

    TARGET_ID                         : origin = 0x308004, length = 0x000001                

    COMPILE_DATE_PREV : origin = 0x308005, length = 0x000001

    COMPILE_DATE : origin = 0x308006, length = 0x00001

    FLASH                                   : origin = 0x30801E, length = 0x02FFE2                  /* On-chip FLASH [0x308000 SectorG hasta 0x338000 sectorB

     

    "BEGIN" is meant to contain functional code, and as such must be aligned to an even address and more importantly must have the flash entry point of 0x308000.

    So we need to make "BEGIN" origin = 0x308000 and move PRG_STATUS to origin = 0x308002, I would also change its length to 0x2 just to block off that odd address

    Even though those other sections are data containers(and if they only had 1 16-bit word odd address would be OK), I would be more comfortable changing their origins to even aligned addresses as well.  So if you could bump TARGET_PREV to 308004 and length to 0x2, etc for the other sections that should resolve things.

    Best,

    Matthew