• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 81 subscribers
  • Views 3462 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.

Issue when programming with MSP-FET430UIF

Akila Halawatha
Prodigy 50 points
Other Parts Discussed in Thread: MSP430F2418, MSP-FET

Hello,

 

I am using FET-Pro430 software with MSP-FET430UIF programmer (via JTAG) to program a MSP430F2418 micro-controller. My program didn't flash properly in the below scenario.

 

I have two codes in TI-TXT format (code1 and code2). Both the codes are flashing and working perfectly. I want to combine the two codes and flash it. Their address spaces do not intersect with each other except in the interrupt vector space (Address range 0xFFC0 - 0xFFFF). What I want to do for the interrupt vector space is that,

Use 0xFFC0 - 0xFFFD range interrupt vector data from code2

Use 0xFFFE - 0xFFFF (which is the reset address) data from code1.

 

So my combined code has the following components

1. Code data from code1 except interrupt vector data

2. Code data from code2 except interrupt vector data

3. Reset address from code1

4. All other interrupt vector data from code2

 

When I tried to flash this combined code, writing was completed successfully but when I read back interrupt vector data (0xFFC0 - 0xFFFF) was not written.

If I am elaborating more, these are things I did,

1. Opened the combined code file written in TI-TXT format - It was read properly by FET-PRO430

2. Erasing and blank checking was done successfully

3. Writing and verifying (PSA for verification) was completed successfully

4. Read back and the compared with original data. But interrupt vector data (0xFFC0 - 0xFFFF) was not matching.

 

In order to verify weather there is an issue with the combination I flashed these combinations also

Combination1

1. Code data from code1 except interrupt vector data

2. Code data from code2 except interrupt vector data

3. Interrupt vector data from code2

 

Combination2

1. Code data from code1 except interrupt vector data

2. Code data from code2 except interrupt vector data

3. Interrupt vector data from code1

 

Both of the above combinations flashed and worked and perfectly.

 

Any ideas about the issue ?

 

Details of my tools are

 

FET-Pro430 software version - 3.4-0

MSP-FET430UIF firmware version - 3.05.01.001

MSP-FET430UIF hardware version - 1.4a

Thanks in advance

  • 0
    TI__Guru**** 218507 points
    Hello Akila,

    Would it be possible to provide your combined TI TXT file? There could be an issue with this file's format or address lines that prevents the FET-Pro430 from writing the interrupt vector data correctly. At any rate I do not think the issue lies with the MSP-FET430UIF hardware or firmware.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 50 points

    Hello Ryan,

    Thanks for the reply.

    Herewith I have attached the combined code file. 

    Regards,

    Akila

    code_combined.txt

  • 0 in reply to Akila Halawatha
    Guru 34483 points

    I don't see any problem in txt file, and don't see any reason for any flashing tool to not have multi-files possibility.

    My flasher can use multiple files ...

    flash -p com4 -e -f file1.txt -w -v -f file2.txt -w -v ...

  • 0 in reply to Akila Halawatha
    TI__Guru**** 218507 points
    Hi Akila,

    I've been able to replicate your issue using the same tools. If using the MSP-FET the interrupt vector will show all 0xFF instead of corrupted values. Through user-defined memory writing I've discovered that the error occurs once you write from address 0x12500 to 0x12515 (22 bytes), afterwards clearing or corrupting the interrupt vector values. Do you know what instructions are stored at these addresses?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Guru 58965 points

    Ryan,

    They look like silly functions that return one byte (from InfoA memory or a constant 1) and an endless loop trap for the CPU.

    0124F6    425C 1040          mov.b   &0x1040,R12

    0124FA    0110               reta

    0124FC    425C 109F          mov.b   &0x109F,R12

    012500    0110               reta

    012502    425C 10A0          mov.b   &0x10A0,R12

    012506    0110               reta

    012508    421C 10A2          mov.w   &0x10A2,R12

    01250C    0110               reta

    01250E    431C               mov.w   #0x1,R12

    012510    0110               reta

    012512    4303               nop

    012514    3FFF               jmp     0x12514

  • 0
    Prodigy 50 points

    Hello all,

    Thanks for your co-operation.

    What contains in the address range 0x10000 - 0x12515 is the extended code memory of the code1. I have used proprietary TI compiler for MSP430 (version v4.4.3).

    In the address range you have mentioned above (0x12500 to 0x12515) there are several things which is necessary for my requirement. There are several flags and variables I have stored in the information memory.

    1. InfoC - 0x1040

    2. InfoB - 0x109F, 0x10A0, 0x10A1-0x10A2

    Those will be manipulated permanently when certain events are triggered. So what 0x124F6-0x12511 does is that returning those stored flags and variables.  NOP and the JUMP instructions are normally placed by TI compiler at the end of a code.

    Ryan,

    I too noticed 0xFFs in the interrupt vector space.

  • 0 in reply to Akila Halawatha
    TI__Guru**** 218507 points
    Hey Akila,

    Agreed that nothing malicious is happening with the memory space in question. I'm currently discussing the issue with an Elprotronic engineer to decide whether the issue is related to the FET-Pro430 software, I will return with their reply as soon as possible.

    Regards,
    Ryan
  • 0
    Prodigy 50 points

    Hello Ryan,

    Any updates from Elprotronic side?

  • 0 in reply to Akila Halawatha
    TI__Guru**** 218507 points
    Not yet Akila, I will ping them again and return with their response as soon as it is given.

    Regards,
    Ryan
  • 0 in reply to Akila Halawatha
    TI__Guru**** 218507 points
    Akila,

    Elprotronic has responded that they contacted you offline to further address the problem.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    TI__Guru**** 218507 points
    This issue was closed offline, an explanation of the issue from Elprotronic is as follows:

    As mentioned earlier in the thread programming and verification the first time is OK. That verification is done after programming without resetting the MCU. Next verification (after resetting the MCU) was wrong because the firmware modifies the flash contents. Just to confirm that all programming was OK with combined code the reset address was changed from the real one to 0xFFFF. When that was done, then contents of the interrupt vector was always OK – after first and second verification. Also contents read back compared with the code contents (combined code) was always the same. That means – the flash is modified only during firmware start. Suggestions including checking firmware to find out what and how the interrupt vector is modified by the firmware. As the first step – change the address of the reset vector to 0xFFFF and observe that all contents in flash is always OK. That confirms the programming is correct.

    Regards,
    Ryan
  • 0
    Prodigy 50 points

    Hello Ryan,

    I found the issue and solved the case using a workaround. Thanks for the support.

**Attention** This is a public forum